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Abstract 


BGP  is  unique  among  IP-routing  protocols  in  that  rout¬ 
ing  is  determined  using  semantically  rich  routing  poli¬ 
cies.  However,  this  expressiveness  has  come  with  hidden 
risks.  The  interaction  of  locally  defined  routing  policies 
can  lead  to  unexpected  global  routing  anomalies,  which 
can  be  very  difficult  to  identify  and  correct  in  the  de¬ 
centralized  and  competitive  Internet  environment.  These 
risks  increase  as  the  complexity  of  local  policies  increase, 
which  is  precisely  the  current  trend.  BGP  policy  lan¬ 
guages  have  evolved  in  a  rather  organic  fashion  with  lit¬ 
tle  effort  to  avoid  policy-interaction  problems.  We  be¬ 
lieve  that  researchers  should  start  to  consider  how  to  de¬ 
sign  policy  languages  for  path-vector  protocols  in  order 
to  avoid  routing  anomalies  while  obtaining  desirable  pro¬ 
tocol  properties.  We  take  a  few  steps  in  this  direction  by 
identifying  the  important  dimensions  of  this  design  space 
and  characterizing  some  of  the  inherent  design  trade-offs. 
We  do  this  in  a  general  way  that  is  not  constrained  by  the 
details  of  BGP. 
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1  Introduction 

The  Border  Gateway  Protocol  (BGP)  is  the  dynamic  rout¬ 
ing  protocol  used  to  connect  autonomously  administered 
networks  on  the  Internet  [12,  21,  25].  BGP’s  main  task 
is  to  establish  and  maintain  best-effort  connectivity,  even 
in  the  face  of  large-scale  network  outages.  This  con¬ 
trasts  with  other,  more  familiar  IP-routing  protocols  such 
as  OSPF  and  IS-IS,  whose  main  task  is  to  establish  and 
maintain  connectivity  within  a  single  administrative  do¬ 
main  [14], 

BGP  is  unique  among  IP-routing  protocols  in  that  rout¬ 
ing  is  determined  using  semantically  rich  routing  policies. 
It  is  important  to  note  that  the  languages  and  techniques 
for  specifying  BGP  routing  policies  are  not  actually  a  part 
of  the  protocol.  The  BGP  specification  (RFC  1771  [21]) 
merely  describes  the  low-level  binary  formats  of  BGP 
update  messages,  the  intended  meaning  of  the  fields  in¬ 
cluded  in  update  messages,  and  the  correct  operation  of  a 
BGP-speaking  router.  On  the  other  hand,  routing-policy 
languages  have  been  developed  by  router  vendors  and 
have  evolved  through  interactions  with  network  engineers 
in  an  environment  lacking  vendor-independent  standards. 
Vendors  typically  provide  hundreds  of  special  commands 
for  use  in  the  configuration  of  BGP  policies.  In  addition, 
BGP  communities  (RFC  1997  [3])  allow  policy  writers 
to  selectively  attach  tags  to  routes  and  use  these  to  signal 
policy  information  to  other  BGP-speaking  routers.  Rout¬ 
ing  policies  can  then  condition  their  behavior  on  the  pres¬ 
ence  or  absence  of  specific  community  values.  These  de¬ 
velopments  have  more  and  more  given  the  task  of  writing 
BGP  configurations  aspects  associated  with  open-ended 
programming.  This  allows  network  operators  to  encode 
complex  policies  in  order  to  address  unforeseen  situations 
and  has  opened  the  door  for  a  great  deal  of  creativity  and 
experimentation  in  routing  policies. 

However,  this  rich  expressiveness  has  come  with  hid- 
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den  risks.  The  interaction  between  locally  defined  rout¬ 
ing  policies  can  lead  to  unexpected  global  routing  anoma¬ 
lies  such  as  nondeterministic  routing  and  protocol  diver¬ 
gence  [9,  26],  If  the  interacting  policies  causing  such 
anomalies  are  defined  in  separate,  autonomously  admin¬ 
istered  networks,  then  these  problems  can  be  very  diffi¬ 
cult  to  debug  and  correct.  For  example,  the  setting  of  an 
attribute  in  one  autonomous  system  to  implement  “cold- 
potato  routing”  can  cause  protocol  divergence  in  a  neigh¬ 
boring  autonomous  system  [4,  18].  We  suspect  that  such 
problems  will  only  become  more  common  as  BGP  con¬ 
tinues  to  evolve  with  richer  policy  expressiveness.  For  ex¬ 
ample,  extended  communities  [20]  provide  an  even  more 
flexible  means  of  signaling  information  within  and  be¬ 
tween  autonomous  systems  than  the  original  definition  [3] 
did.  At  the  same  time,  applications  of  communities  by 
network  operators  are  evolving  to  address  complex  issues 
of  interdomain  traffic  engineering  [2] . 

We  believe  that  the  root  cause  of  “BGP-configuration 
problems”  is  a  lack  of  design  for  the  policy  languages 
that  are  used  to  configure  this  protocol.  BGP  policy  lan¬ 
guages  have  evolved  in  a  rather  organic  fashion  with  little 
or  no  effort  made  to  avoid  policy-interaction  problems. 
We  believe  that  researchers  should  start  to  consider  how 
to  design  policy  languages  and  path- vector  protocols  that 
together  avoid  such  risks  and  yet  retain  other  desirable 
features.  We  take  a  few  steps  in  this  direction  by  identi¬ 
fying  the  important  dimensions  of  this  design  space  and 
characterizing  some  of  the  inherent  design  trade-offs.  We 
do  this  in  a  general  way  that  is  not  constrained  by  the  de¬ 
tails  of  BGP.  As  a  result,  our  framework  may  offer  guid¬ 
ance  not  only  in  the  analysis  of  proposals  to  correct  or  ex¬ 
tend  BGP  but  also  in  the  analysis  of  other  BGP -like  proto¬ 
cols  such  as  a  version  of  BGP  supporting  Virtual  Private 
Networks  [22],  Telephony  Routing  over  IP  (TRIP)  [23], 
and  of  various  proposals  for  interdomain  routing  of  opti¬ 
cal  paths  [19,  27]. 

1.1  Overview  of  the  Design  Space 

We  feel  that  our  main  contribution  is  in  the  identifica¬ 
tion  of  the  design  goals  of  policy  languages  and  path- 
vector  protocols.  In  addition,  we  formalize  these  goals 
and  path-vector  implementations  in  a  way  that  allows  in¬ 
herent  trade-offs  to  be  rigorously  characterized. 


We  identify  six  important  design  goals  for  any  path- 
vector  protocol  and  policy  language: 

Expressiveness.  From  the  perspective  of  a  network  oper¬ 
ator,  we  desire  policy  languages  that  are  as  expressive  as 
possible.  For  example,  shortest-path  routing  is  not  expres¬ 
sive  enough  for  the  requirements  of  current  interdomain 
routing  because  it  is  unable  to  capture  the  “natural”  rout¬ 
ing  conditions  arising  from  the  pervasive  economic  roles 
of  customer,  provider,  and  peer  [15,  16],  The  challenge 
then  is  to  design  policy  languages  that  are  as  expressive 
as  possible,  and  yet  not  so  expressive  that  other  design 
goals  are  sacrificed. 

Robustness.  We  require  predictability,  i.e.,  that  any  non¬ 
determinism  in  routing  policies  is  not  the  result  of  un¬ 
wanted  policy  interactions,  and  the  existence  of  a  routing 
solution  which  is  always  found  by  the  protocol  (this  pre¬ 
vents  protocol  divergence).  Furthermore,  we  insist  that 
the  same  is  true  of  any  configuration  that  results  from  any 
combination  of  link  and  node  failures  in  the  network.  The 
goal  of  robustness  is  the  primary  constraint  on  the  expres¬ 
sive  power  of  a  policy  language;  we  are  generally  uninter¬ 
ested  in  non-robust  policies. 

Autonomy.  Network  operators  often  require  a  high  de¬ 
gree  of  autonomy  when  defining  routing  policies.  We 
may  have  a  good  intuition  about  what  this  means — that 
policy  writers  are  given  wide  latitude  in  defining  poli¬ 
cies  that  reflect  their  own  interests  and  not  the  interests  of 
their  neighbors.  Here,  generalized  autonomy  will  mean 
the  ability  to  define  a  partition  on  routes  and  then  rank 
the  partition  classes  arbitrarily.  Operationally,  autonomy 
is  important  because  it  isolates  an  autonomous  system 
from  policy  changes  occurring  in  other  (neighboring  or 
distant)  autonomous  systems.  Without  a  high  degree  of 
autonomy,  network  operators  would  have  to  continually 
“tweak”  their  policies  to  compensate  for  unseen  changes 
made  to  policies  elsewhere. 

In  addition  to  a  generalized  definition,  we  present  one 
notion  of  autonomy  important  for  BGP — autonomy  of 
neighbor  ranking — that  allows  policy  writers  to  classify 
neighbors  and  set  route  preferences  in  accordance  with 
this  classification.  This  type  of  autonomy  is  required  for  a 
BGP  policy  language  to  support  policies  compatible  with 
present-day  commercial  realities  of  the  Internet. 

Protocol  Transparency.  Many  “obvious”  approaches  to 
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achieving  very  expressive  and  robust  systems  involve  a 
high  cost;  they  add  machinery  that  is  invisible  to  policy 
writers  to  the  underlying  path-vector  system.  What  is  lost 
is  protocol  transparency — the  ability  of  network  opera¬ 
tors  to  understand  the  semantics  of  policies  they  write.  If 
the  protocol  itself  is  allowed  to  dynamically  modify  the 
input  policies  (in  order  to  ensure  robustness,  for  exam¬ 
ple),  then  it  may  become  very  difficult,  if  not  impossible, 
to  maintain  and  debug  routing  policies. 

Global  Consistency.  One  way  to  achieve  robustness  is  to 
implement  a  mechanism  enforcing  a  global-consistency 
constraint  that  guarantees  robustness.  This  constraint 
could  be  enforced  in  any  number  of  ways,  including  an 
additional  protocol  or  set  of  protocols,  by  convention,  by 
regulation,  by  economic  incentives,  or  by  some  combina¬ 
tion  of  methods.  Of  course,  the  easier  such  a  constraint  is 
to  check,  the  better.  We  note  that  in  the  current  Internet, 
there  is  no  global-consistency  checking  of  BGP  policies. 

Policy  Opaqueness.  This  design  goal  measures  the  de¬ 
gree  to  which  details  of  routing  policies  are  to  be  kept  pri¬ 
vate  or  hidden  from  those  outside  of  a  routing  domain  (the 
term  is  from  Geoff  Huston  [17]).  Full  policy  opaqueness 
is,  of  course,  in  direct  conflict  with  any  sort  of  global- 
consistency  enforcement.  Therefore,  the  design  challenge 
is  to  find  a  happy  medium  that  allows  for  the  exposure  of 
just  enough  information  to  ensure  robustness  while  at  the 
same  time  allowing  for  a  sufficient  amount  of  information 
hiding  to  satisfy  policy  writers. 

Our  formalization  starts  with  defining  three  distinct 
components  of  any  path-vector  protocol:  the  underlying 
path-vector  system,  the  policy  language,  and  any  global 
consistency  assumptions  about  the  network.  The  path- 
vector  system  should  be  thought  of  as  the  low-level  means 
of  carrying  messages  between  systems,  much  like  RFC 
1771.  Section  2  presents  a  definition  for  path-vector  sys¬ 
tems  that  formalizes  the  information  that  nodes  exchange, 
various  restrictions  on  nodes’  behavior,  and  the  way  that 
protocols  mediate  interactions  between  nodes.  As  we  de¬ 
fine  various  components,  we  illustrate  them  with  a  run¬ 
ning  example  that  models  BGR  Additional  examples  are 
given  in  Section  3. 

We  separate  the  definition  of  a  path-vector  system  from 
the  definition  of  a  policy  language:  a  policy  language  is 
a  high-level  declaration  of  how  the  attributes  describing  a 


route  change  when  the  route  is  exchanged  between  neigh¬ 
bors.  Section  2.3  defines  the  intended  role  of  policy  lan¬ 
guages  in  path-vector-system  configuration. 

The  notions  of  expressiveness  and  robustness  are  for¬ 
malized  in  Sections  4  and  5.  For  both  we  employ  the 
Stable  Paths  Problem  (SPP)  [9]  as  a  semantic  model  of 
path-vector  systems.  We  identify  one  class  of  robust  sys¬ 
tems  as  our  target  for  expressiveness  (Definition  5.4  and 
Theorem  5.10).  Autonomy  and  transparency  are  formal¬ 
ized  in  Sections  6.1  and  6.2.  Policy  opaqueness  is  briefly 
discussed  in  Section  6.4,  while  global  constraints  are  con¬ 
sidered  in  Section  7. 

Besides  the  more  obvious  trade-offs  already  men¬ 
tioned,  we  identify  several  more  subtle  ones: 

1 .  Any  system  with  a  policy  language  that  is  maximally 
expressive  but  has  no  global  constraint  must  give  up 
either  autonomy  of  neighbor  ranking  or  transparency 
(or  both)  (Theorem  6.9). 

2.  Any  autonomous,  transparent,  and  robust  system 
with  a  policy  language  at  least  as  expressive  as 
shortest-path  routing  must  have  a  non-trivial  global 
constraint  (Theorem  7.4). 

These  results  tell  us  that,  if  we  seek  to  design  expres¬ 
sive  policy  languages  that  are  transparent,  autonomous, 
and  robust,  then  we  must  consider  the  global  constraint 
as  an  integral  part  of  the  design.  Indeed,  current  path- 
vector  protocols  may  succeed  in  part  because  of  assump¬ 
tions  about  the  global  network;  our  framework  highlights 
the  importance  of  this  component  of  design. 

Figure  1  illustrates  the  design  space  for  robust  and 
transparent  path-vector  policy  systems.  (This  figure  is 
meant  to  aid  in  developing  intuitions,  and  should  not  be 
taken  too  literally.)  The  x-axis  represents  the  expressive 
power  of  systems,  and  the  y-axis  represents  the  relative 
difficulty  of  checking  the  global  constraint.  Combinations 
of  path-vector  systems  and  policy  languages  which  fall 
close  to  the  bottom  right  of  Figure  1  are  generally  desir¬ 
able. 

Some  points  in  the  space  deserve  attention.  On  the 
bottom  horizontal  line  lie  systems  that  require  no  global 
constraint  to  be  robust.  In  this  paper,  we  assume  “min¬ 
imal”  expressiveness  is  “Shortest-Paths”  routing;  a  sim¬ 
ple  extension  to  this  is  “Shortest- Available  Paths,”  which 
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Figure  1:  Design  space  for  robust  and  transparent  path-vector  systems. 


allows  routes  to  be  filtered  (even  if  they  are  the  short¬ 
est)  and  chooses  the  shortest  path  from  the  remaining 
routes.  (Both  examples  are  given  in  Section  3.)  We  take 
“maximal”  expressiveness  to  be  the  expressive  power  of 
a  natural  class  of  robust  systems  that  we  define  in  Sec¬ 
tion  5.3.  Two  possible  systems  which  possess  the  prop¬ 
erty  “Globally  Increasing  Path  Ranking”  are  discussed  in 
Section  6.3;  while  these  achieve  maximal  expressiveness 
with  no  global  constraint,  they  sacrifice  other  design  goals 
in  the  process.  The  final  extreme  point,  “Robust  BGP,”  is 
a  system  in  which  all  BGP  policies  are  collected  and  veri¬ 
fied  not  to  contain  conflicting  policies.  One  might  use  the 
Routing  Policy  Specification  Language  (RPSL)  [1]  in  the 
manner  suggested  in  [7]  to  accomplish  this.  Many  practi¬ 
cal  issues  make  this  scenario  unlikely;  furthermore,  it  was 
shown  in  [10]  that,  in  the  worst  case,  checking  various 
global-consistency  constraints  is  NP-hard. 

Hierarchical  BGP  systems  (inspired  by  [5,  6])  provide 
examples  from  today’s  commercial  Internet.  Figure  1  in¬ 
cludes  the  system  CP,  a  BGP-like  system  in  which  the 
policy  language  allows  nodes  to  classify  neighbors  as 
customers  and  providers  and  to  rank  routes  consistent 
with  those  relationships;  CP  is  robust  if  there  are  no  cy¬ 


cles  in  the  customer/provider  graph  and  if  classifications 
of  neighbors  are  consistent.  We  might  increase  the  ex¬ 
pressiveness  of  this  system  in  two  ways:  (1)  allow  an 
additional  classification  of  neighbors  as  peers,  in  which 
case  we  must  modify  the  global  constraint  to  addition¬ 
ally  check  the  consistency  of  peer  classifications  (the  sys¬ 
tem  HBGP);  or  (2)  modify  the  policy  language  to  per¬ 
mit  marking  routes  for  backup  use  (the  system  CP+BU). 
Combining  both  approaches  achieves  the  expressiveness 
of  the  system  HBGP+BU.  These  types  of  systems  are  dis¬ 
cussed  in  Section  8.  Note  that  in  the  real  world,  there  are 
no  existing  methods  to  enforce  either  the  local  or  global 
constraints,  although  Internet  economics  seems  to  ensure 
that  networks  behave  in  close  approximation  to  the  rules 
described  by  the  above-mentioned  robustness  conditions. 

2  Path-Vector  Policy  Systems 

In  this  section,  we  define  the  “protocol  part”  of  our  frame¬ 
work:  the  underlying  exchange  system  for  route  informa¬ 
tion.  We  sketch  the  components  independent  of  any  par¬ 
ticular  system  or  instance  of  a  system.  Using  the  defini- 
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tions  presented  here,  we  can  rigorously  explore  the  proto¬ 
col  design  space  in  later  sections. 

2.1  Dynamics  of  Path- Vector  Routing 

We  first  briefly  discuss  the  intended  dynamics  of  routing 
using  a  path-vector  system,  as  this  motivates  the  system 
components  we  define  in  our  framework. 

Informally,  let  each  node  in  the  network  be  a  protocol¬ 
speaking  router  responsible  for  its  autonomous  domain. 
A  node  advertises  destinations  in  its  network  to  its  neigh¬ 
bors,  and  they  further  transmit  this  information  to  their 
neighbors,  etc.  Whenever  a  router  gets  new  information 
about  a  destination,  it  determines  the  best  route  to  that 
destination  given  all  the  up-to-date  information  it  has  col¬ 
lected.  We  expect  that  routers  will  influence  these  deci¬ 
sions  by  modifying  route  attributes.  This  can  be  done  on 
export,  when  routes  are  advertised  to  neighbors  (or  pos¬ 
sibly  filtered  out  altogether),  or  on  import,  when  data  are 
collected  and  stored  for  decision-making. 

Therefore,  we  assume  that  there  is  some  data  structure 
to  store  and  exchange  route  information,  and  that  trans¬ 
formations  to  these  data  structures  are  made  on  import 
and  export  as  dictated  by  routers’  policy  configurations. 
The  exchange  of  these  data  structures  between  neighbors 
as  described  above  will  eventually  permeate  the  network 
with  knowledge  about  the  various  destinations  originated 
by  routers.  Comparing  these  data  structures  gives  a  “best” 
route  to  a  destination. 

2.2  Formal  Definition  of 
Path- Vector  Systems 

As  we  develop  our  framework,  we  will  use  a  simplified 
model  of  BGP  as  a  running  example.  This  example  model 
assumes  that  each  node  (router)  represents  an  entire  au¬ 
tonomous  system  and  thus  treats  only  External  BGP  (not 
Internal  BGP).  It  also  ignores  most  BGP  attributes  and 
simplifies  others.  We  will  adorn  the  elements  of  this  ex¬ 
ample  system  with  the  subscript  p.bgp. 

2.2.1  Route  Information 

A  path  descriptor  is  a  data  record  about  a  path  that  con¬ 
tains  enough  information  (e.g.,  the  routing  destination,  the 
sequence  of  AS  numbers  along  the  entire  path,  routers’ 


preference  values  for  the  path,  transmission  cost,  etc.)  for 
a  router  to  compare  it  to  other  paths  and  to  inform  its 
neighbors  about  the  path  so  that  they  can  do  the  same.  A 
router  learns  of  paths  by  receiving  descriptors  from  neigh¬ 
bors  and  preserves  knowledge  of  potential  best  routes  by 
storing  descriptors  for  paths  to  all  known  destinations. 

The  path-vector-system  specification  includes  a  de¬ 
scription  of  the  components  in  a  path  descriptor  and  a 
map  that  ranks  them  using  values  from  a  totally  ordered 
set.  This  ranking  permits  routers  to  determine  best  routes 
based  on  just  the  information  contained  in  the  available 
descriptors  to  a  destination;  in  particular,  the  rank  of  a 
descriptor  depends  only  on  that  descriptor.  Determining 
rank  normally  involves  some  components  of  path  descrip¬ 
tors  that  can  be  transformed  by  both  locally  configured 
policies  and  the  underlying  message-exchange  protocol 
itself. 

Definition  2.1.  Let  the  quadruple 

1=  (V,  1Z,  U,  uj) 

be  the  route-information  portion  of  the  path-vector- 
system  specification.  The  components  are  defined  as  fol¬ 
lows; 

V  is  the  set  of  possible  routing  destinations; 

7Z  is  the  set  of  path  descriptors,  such  that  to  every  r  £  1Z 
there  must  be  associated  a  unique  dest(r)  £  T>; 

U  is  a  set  totally  ordered  by  <;  and 

u>  is  a  function  (the  ranking  function)  from  IZtaU  that 
determines  how  path  descriptors  are  ranked  (thus,  the 
role  of  path-descriptor  attributes  in  choosing  routes). 

Remark  2.2.  Although  the  mechanics  of  determining 
“best”  routes  will  be  discussed  in  Section  2.6,  we  observe 
the  convention  that  the  ranking  function  will  map  more 
preferred  paths  to  smaller  elements  of  U. 

Running  Example,  Part  1.  In  our  example  system,  let 
V  be  the  set  of  all  IPv4  CIDR  blocks.  Let  the  set  of  path 
descriptors  be 

T^r-bgp  =  T^pbgp  xNx  Seq(N)  x  N  x  2C, 

where  N  is  the  set  of  natural  numbers,  Seq(N)  is  the  set 
of  finite  sequences  of  natural  numbers,  and  C  is  the  set 
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{red,  blue,  green}.  If  r  =  ( d ,  l,  P ,  n,  5)  G  TZpbgp, 
then  d  is  the  destination  of  r,  l  is  the  local  preference,  P 
is  the  AS  path,  n  is  the  next  hop,  and  the  elements  of  S 
are  the  colors  of  r.  Colors  are  meant  to  be  a  very  simple 
model  of  BGP  communities  [3], 

Let  U^bgp  =  N  x  N  x  N  and  w((ci,  l ,  P,  n,  S))  = 
(l,  |P|,  n),  with  the  ordering  <p,bgp  on  Ulthrw  given  by 
( l ,  m,  n )  </j,bgP  {l',  to/,  n ')  if  and  only  if: 

l  >  l';  or 

l  =  l',  to  <  to';  or 

1  =  1',  to  =  to',  n  <  if . 

The  combination  of  <p,bgp  and  co^bgp  prefers  higher  lo¬ 
cal  preference,  with  ties  broken  by  preferring  smaller  AS- 
path  length  and  then  smaller  value  of  the  next  hop. 

2.2.2  Import  and  Export  Policies 

Path-vector  systems  explicitly  include  operations  for  im¬ 
porting  routes  from  neighbors  and  exporting  routes  to 
neighbors.  Router  operators  provide  separate  import  and 
export  configuration  policies  to  describe  router  behavior 
when  exchanging  route  information,  e.g.,  to  change  path- 
descriptor  attributes  for  a  route  affecting  its  rank  or  to  fil¬ 
ter  out  routes  altogether.  The  set  of  node  policies  across 
the  network  would  therefore  be  a  component  of  a  spe¬ 
cific  instance  of  the  path-vector  system.  On  a  low  level, 
the  import  and  export  policies  are  per-neighbor  functions 
on  path  descriptors  that  transform  their  components  to 
make  preference  changes  in  accordance  with  local  pol¬ 
icy.  We  expect  that  policies  will  usually  be  written  in  a 
higher-level  policy  language,  which  motivates  the  policy- 
language  component  of  design. 

A  path-vector  system  includes  local-policy  constraints 
on  what  import  and  export  policies  are  allowed.  These 
limits  on  the  expressiveness  of  local  policies  can  help 
guarantee  robustness  and  can  help  ensure  that  a  protocol 
achieves  its  goals;  e.g.,  if  policies  can  only  add  a  positive 
value  to  a  path-cost  attribute  that  alone  determines  path 
rank,  the  path-vector  system  implements  lowest-cost-path 
routing. 

Formally,  let  elements  of  the  function  space  2K  — »  2n 
be  called  policy  functions  (these  are  functions  on  sets 
of  path  descriptors,  thus  describing  transformations  on 
them).  We  then  define  local-policy  constraints  in  the  fol¬ 
lowing  way. 


Definition  2.3.  Let  the  triple 

C  =  (LOT,  Lout,  o) 

be  the  local-constraints  portion  of  the  path-vector-system 
specification.  Lm  and  Lout  are  predicates  on  import  and 
export  policy  functions,  respectively.  If  L  m  (/)  or  Lout  (/) 
holds,  then  /  is  a  legal  local-policy  function.  Further¬ 
more,  we  assume  that  if  either  L  “(/)  or  L  out(f)  holds, 
then  /  satisfies: 

(1)  for  each  X  C  K,if\X\  =  1  then  |/(X)|  <  1; 

(2)  for  each  X  CTZ,  f(X)  =  Ur6X  /(M);  and 

(3)  for  each  n,  r2  G  1Z,  if  /({?r})  =  {^2}.  then 
dest(r\ )  =  dest(r2). 

O  is  a  predicate  defined  on  subsets  of  1Z  used  to  define 
what  sets  of  path  descriptors  can  be  originated  at  a  node. 
A  node  can  only  advertise  newly  originated  destinations 
described  by  X  C  7Z  if  o(X)  holds. 

Running  Example,  Part  2.  In  our  simplified-BGP  exam¬ 
ple,  we  want  policies  to  affect  only  the  local-preference 
and  colors  (communities)  attributes  of  path  descriptors. 

We  let  L™bgP(f) and  l°Xp^  hold  if  and  only if  /  satis‘ 

fies  conditions  (l)-(3)  above  as  well  as 

(4)  f((d,  l,  P,  n,S ))  =  { (d1,  V,  P’,  nf  5')}  implies 
d!  =  d,  P'  =  P,  and  n'  =  n. 

Additionally,  the  only  path  descriptors  which  may  be 
originated  by  nodes  are  those  with  an  AS  path  contain¬ 
ing  the  AS  alone  (because  the  destination  should  be  in 
the  originating  AS’s  domain)  and  a  default  local  pref¬ 
erence  of  0,  so  we  let  0^bgP{X)  be  true  if  and  only  if 
(d,  l,  P,  n,  S)  G  X  implies  l  =  0  and  P  =  v  where  v  is 
the  originating  AS. 

2.2.3  Application  of  Policies 

Although  import  and  export  policies  allow  router  oper¬ 
ators  to  configure  their  routers,  we  must  recognize  that 
it  is  the  router  (or  the  protocol  itself)  actually  applies 
those  policies  to  path  descriptors  encountered  while  run¬ 
ning  the  protocol.  Therefore,  path-vector-system  spec¬ 
ifications  include  a  policy-application  function  for  both 
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the  import  and  export  operations.  These  functions  de¬ 
scribe  the  transformations  used  by  the  protocol  to  apply 
operator-provided  policies  to  path  descriptors.  This  al¬ 
lows  the  application  of  policies  to  be  consistent  with  the 
goals  of  the  protocol,  e.g.,  routers  may  only  apply  poli¬ 
cies  when  they  satisfy  a  local  condition  guaranteeing  ro¬ 
bustness.  These  functions  are  often  used  to  make  changes 
to  path  descriptors  uniformly  throughout  all  information 
exchanges  in  addition  to  applying  the  operator-provided 
configuration  policy  (e.g.,  appending  a  node  name  to  the 
described  path  or  hiding  certain  attributes  when  they  con¬ 
tain  private  information).  Formally,  we  have 

Definition  2.4.  Let  the  pair 

in  j.Ollt^ 

be  the  protocol-transformation  portion  of  the  path-vector- 
system  specification.  Both  tm  and  tout  are  functions  of 
type  (N  x  N  x  ( 2K  — >  2K)  x  2n)  — >  2n\  the  first  two 
arguments  are  node  names,  the  third  is  the  policy  function 
to  apply,  the  fourth  is  the  target  set  of  path  descriptors. 

Running  Example,  Part  3.  We  now  give  the  protocol 
transformations  for  our  model  of  BGP.  If  u  and  v  are 
nodes,  /  is  a  policy  function  (expected  to  be  u’s  export 
policy  function  for  v),  and  X  is  a  set  of  path  descriptors 
(expected  to  be  known  to  u ),  then 

/’  X)  =  {(d»  °»  vP>  S) 

|  (d,  m ,  P,  w,  S)  G  f(X)}. 

The  protocol  applies  the  (export)  policy  function  (which 
may  change  local  preference  and  colors)  and  then  updates 
the  AS-path  and  next-hop  values  to  reflect  the  edge  {u,  v } 
in  the  extended  path.  It  also  sets  the  local  preference  value 
to  0,  hiding  this  value  from  the  node  receiving  information 
about  this  path.  If  Y  is  a  set  of  path  descriptors  (expected 
tob (u,  v,  f,  X))  and  <7  is  Ps  import  policy  func¬ 
tion  for  u,  then  we  let 

t£bgp(v’  u >  9,  Y)  =  { g(r )  \  r&Y, 

r  describes  a  simple  path} . 

The  protocol  thus  takes  care  of  filtering  any  paths  which 
contain  loops. 


2.2.4  Path-Vector  System 

Definition  2.5.  A  path-vector  system  is  a  triple  of  the 
form 

PV  =  ( 1 ,  C,  T) 

where  the  components  are  as  defined  in  Definitions  2.1- 
2.4. 

2.3  Policy  Languages 

Of  course,  policy  writers  don’t  actually  write  mathemat¬ 
ical  functions,  but  rather  write  specifications  in  a  path- 
vector  policy  language.  We  expect  that  such  languages 
can  be  given  a  rigorous  semantics  so  that  policies  written 
in  the  language  can  be  treated  as  specifications  for  func¬ 
tions  on  path  descriptors.  A  policy  language  essentially 
is  a  local  constraint  on  the  policy  functions  that  can  be 
written  for  a  path-vector  system.  Policy-language  design¬ 
ers  must  ensure  that  legal  policy  specifications  are  guar¬ 
anteed  to  have  semantics  that  conform  to  the  constraints 
of  the  target  path-vector  system(s).  In  practice,  this  may 
involve  some  type  of  compilation  to  low-level,  vendor- 
specific  configuration  commands — a  transformation  that 
may  be  rather  complex.  However,  separating  the  defini¬ 
tion  of  a  policy  language  from  the  definition  of  a  path- 
vector  system  allows  us  to  consider  multiple  policy  lan¬ 
guages  for  the  same  path-vector  system.  We  can  also  dis¬ 
cuss  using  different  path-vector  systems  to  implement  the 
same  policy  language. 

Definition  2.6.  A  policy  language  PL  for  a  path-vector 
system  is  a  language  and  a  semantic  function  A4  that  maps 
each  policy  configuration  p  written  in  this  language  to  a 
triple 

M(p)  =  (mm,  mout ,  moris) 

of  partial  functions  of  types 

mm,  mout  :  V  x  V  ->  {2n  2n) 

morig  .  y  _2n 

If  u  and  v  are  node  identifiers,  then  mm(v,  u)  and 
mm(v,  u)  are  called  the  import  and  export  policy  func¬ 
tions  at  v  for  u,  respectively,  and  Lm(mm(v,  u))  and 
L out(mout(v,  u))  hold  whenever  these  policy  functions 
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are  defined.  These  functions  transform  sets  of  path  de¬ 
scriptors.  Finally,  the  function  in on9  maps  node  identi¬ 
fiers  v  to  finite  subsets  of  1Z  such  that  o(mon9  (i>))  holds 
whenever  mon9(v)  is  defined. 

We  take  policy  configurations  to  be  the  language- 
specific  definitions  of  policies  for  one  or  more  nodes;  the 
set  of  valid  policy  configurations  is  part  of  the  language 
PL. 

Running  Example,  Part  4.  We  define  a  simple  policy 
language  PL^gV.  A  policy  configuration  in  this  language 
is  a  list  of  declarations,  each  having  one  of  the  forms: 

export  from  v  to  IT  :  rule 
import  at  v  from  W  :  rule 
originate  from  v  :  ( d ,  0,  e,  v,  S) 

The  first  and  second  type  declare  export  and  import  poli¬ 
cies,  respectively,  and  the  third  type  declares  routes  to  be 
originated  from  a  node.  The  sets  W  represent  all  of  the 
neighboring  nodes  to  which  a  given  declaration  is  applied. 
Each  rule  is  a  transformation  of  objects  in  'R.g.bgp  defined 
by  a  list  of  clauses: 

Cx  =►  A1 
C2  =►  A2 


where  each  Cj  is  a  boolean  predicate  over  path  descrip¬ 
tors  and  each  At  is  an  action  to  be  taken  on  the  input  path 
descriptor.  The  actions  are  either  of  the  form  reject,  or 
they  are  statements  that  modify  the  local  preference  or 
colors  of  a  path  descriptor.  For  each  path  descriptor  r 
input  to  such  a  rule,  the  action  associated  with  the  first 
predicate  that  evaluates  to  true  is  performed  on  r.  If  no 
clause  matches,  the  empty  set  is  returned.  A4  pr  ,  (p) 
is  easy  to  determine  given  the  form  of  policy  configura¬ 
tions  in  PL^bgp:  see  part  5  of  the  running  example  in  the 
following  subsection. 

2.4  Instances  of  Path-Vector  Systems 

Definition  2.7.  An  instance  of  a  path-vector  system  P  V 
with  respect  to  a  policy  language  PL  (or  an  instance  of 
(PV ,  PL))  is  a  pair 

I=(G,  P), 


where  G  =  (V,  E)  is  an  undirected  graph,  called 
the  signaling  graph,  and  the  configuration  function  P 
maps  nodes  v  £  V  to  policy  configurations  P(v)  = 
pv  in  the  policy  language  PL  so  that  A i(pv)  = 
(Fffi ,  F°wt,  Ffrl'9 ) .  We  require  that  F°n9(v)  is  defined 
and  that,  for  every  {v,  u}  £  E,  both  Ffn(v,  u)  and 
Ffut(v,  u)  are  defined.  We  will  assume  that  the  vertex 
set  V  is  a  subset  of  N. 

Let  F(I)  =  ( Fin ,  Fout,  Fori9)  where 

Fm(v,  u)  =  F™(v,  u) 

Fout(v,  u)  =  F™*(v,  u) 

Fori9(v,  u)  =  |J  FZl9{v) 

w£V 

F  is  a  summary  configuration  function  for  the  instance 
that  represents  the  collection  of  policy  configurations  pro¬ 
vided  by  nodes  in  the  instance.  However,  F  technically 
describes  transformations  on  path  descriptors,  and  thus  is 
a  somewhat  “compiled”  or  “lower-level”  version  of  the 
policies  for  the  instance,  independent  of  the  policy  lan¬ 
guage  used  to  specify  them. 

Remark  2.8.  In  most  cases,  nodes  will  not  originate  de¬ 
scriptors  on  behalf  of  other  nodes,  i.e.,  Fff19^)  =  0  for 
w  /  v,  and  nodes  will  not  have  policies  for  non-incident 
edges,  i.e.,  F™{v,  u),F^ut(v,  u)  are  not  defined  for 
w  /  v.  In  addition,  we  suggest  and  often  assume  that 
the  origination  constraint  includes  a  clause  to  check  that 
nodes  only  originate  path  descriptors  for  destinations  they 
represent  or  contain,  i.e., 

o(X)  =>  [r  £  X  =>  ( destfr )  =  v^r£  Ffri9{v))] 

Definition  2.9.  Given  two  instances  /  =  ( G ,  P)  and 
/'  =  (G1 ,  P')  of  (PV,  PL),  the  instance  V  is  said  to 
be  a  sub-instance  of  I  if  G'  is  a  subgraph  of  G  and  the 
configuration  function  P'  is  equal  to  P  when  restricted  to 
G'.  For  example,  given  any  instance  I  =  ( G ,  P)  and 
G',  a  subgraph  of  G,  the  instance  /'  =  (G' .  P)  is  a  sub¬ 
instance  of  I. 

Running  Example,  Part  5.  One  instance  of 
(PV^bgp,  PLpbgp)  consists  of  the  five-vertex  graph 
shown  in  Figure  2  and  policy  configurations  in  Figure  3. 


Figure  2:  A  simple  5  node  graph. 

2.5  Realizable  Path  Descriptors 

We  are  particularly  interested  in  the  path  descriptors  that 
arise  as  the  result  of  first  originating  a  path  descriptor 
at  some  node  and  then  forwarding  it  along  some  path  in 
the  network,  applying  the  appropriate  export,  import,  and 
protocol  transform  functions  along  the  way.  We  call  these 
realizable  path  descriptors.  Because  we  do  not  usually 
make  use  of  the  path  descriptors  that  arise  after  applying 
an  export  transform  but  before  applying  the  correspond¬ 
ing  input  transform,  we  combine  these  functions  into  arc 
policy  functions  for  convenience. 

Definition  2.10.  Let  I  be  an  instance  of  (PL,  PV )  with 
signaling  graph  G  =  (V,  E)\  let  [v,  it}  £  E  be  any 
edge.  Then  the  arc  policy  function  Ftv,u)  is  the  function 
which  takes  the  path  descriptors  at  u  and  produces  the 
path  descriptors  that  v  has  after  import  from  u.  Thus,  for 
X  cn, 

F{v,u)(X)=tin(v ,  u,  Fin(v,u), 

tout(u ,  v,  Fout(u,v),  X)). 

Note  that  it  may  be  the  case  that  (X)  =  0  for  some 
X  ^  0.  In  this  case  we  say  that  the  path  descriptors  of  X 
have  been  filtered  out  by  F(ViUy 

Conditions  (l)-(3)  given  in  Definition  2.3  only  need 
to  hold  for  the  functions  {F(V)  |  {v,  u}  G  E}\  how¬ 

ever,  because  tout  and  tin  are  specified  separately  from 
the  policies  Fout  and  Fin,  it  may  be  easier  for  those  de¬ 
signing  the  protocol  transformations  t%n  and  tout  to  as¬ 
sume  that  all  policies  satisfying  Lout  or  Lm  also  satisfy 
these  conditions  (and  for  the  compilers  of  policies  into 
functions  to  know  that  it  suffices  to  satisfy  these  condi¬ 
tions). 


originate  from  1  :  ( d ,  0,  (1),  1,  0) 
export  from  1  to  {2}  : 

true  =>  r. colors  :=  {red} 
export  from  1  to  {3,  4}  : 

true  =>■  r. colors  :=  {blue} 
export  from  1  to  5  : 
true  =>  r. colors  :=  {green} 

import  at  2  from  {1,  3,  5}  : 
blue  G  r.colors  =>  r. local-preference  :=  100 
red  G  r.colors  =>  r. local-preference  :=  50 
green  G  r.colors  =>•  r. local-preference  10 

export  from  2  to  {3,  5}  : 
true  =>  r 

import  at  3  from  {1}  : 

true  =>  r.  local-preference  :=  100 
import  at  3  from  {2,  4}  : 
green  G  r.  colors  =>•  r.  local- preference  :=  1000 
blue  G  r.colors  =>  r. local-preference  :=  500 
export  from  3  to  {2,  4}  : 
true  =>  r 

import  at  4  from  {1}  : 

true  =>  r.  local-preference  :=  10 
import  at  4  from  {3,  5}  : 
green  G  r.  colors  =>-  r.  local- preference  :=  50 
blue  G  r.colors  =>  r. local-preference  :=  25 
export  from  4  to  {3,  5}  : 
true  =>  r 

import  at  5  from  {1,  2,  4}  : 
green  G  r.colors  =>  r. local- preference  :=  2 
red  G  r.colors  =>  r. local- preference  :=  1 
export  from  5  to  {2,  4}  : 
true  =>  r 


Figure  3:  Example  policy  configurations  in  PL  ^gp. 

Suppose  that  the  path  P  is  a  simple  path  in  G  from 
a  node  v  to  node  w,  we  write  this  as  a  sequence 
P  =  vxi . . .  XkW  of  distinct  nodes  starting  with  v 
and  ending  with  w.  If  rw  £  Fon9(w ),  then  we  let 
r(P,  rw )  C  K  be  the  result  of  passing  rw  along  P 
and  applying  the  corresponding  arc  policies.  Formally, 
if  P  =  w,  set  r(w,rw )  =  {rw}.  If  v  w  then 
write  P  =  vx\  . . .  XkW  =  vP'  and  let  r(vP',rw )  = 
F(v,xi){r{P' i  fw))- 

Definition  2.11.  The  set  of  path  descriptors  realizable  at 
u  in  I  is  the  set  of  descriptors  which  may  be  originated 
at  u  or  which  may  be  obtained  by  (legally)  originating  a 
descriptor  elsewhere  and  passing  it  along  a  network  path. 


9 


successively  transforming  it  with  the  appropriate  arc  poli¬ 
cies.  Formally: 

nu  =  porig  u 

{r1  G  r(P,  r„,)  w  £  F,  £  Fori9(w), 

and  Pisa  path  from  u  to  w} . 

2.6  Path- Vector  Solutions 

A  solution  for  an  instance  of  a  path-vector  system  is  an 
assignment  of  path  descriptors  to  nodes  which  is  both  re¬ 
alizable  and  which  satisfies  each  node’s  preferences  to  as 
great  an  extent  as  possible  given  the  assignments  to  the 
surrounding  nodes. 

Definition  2.12.  A  path  assignment  p  is  a  mapping  from 
V  to  2k.  Given  a  path  assignment  p,  define  the  set 
C  ( p ,  v)  of  candidates  at  node  v  to  be 

F°™»  U  {r  G  n  |  {v,  u}  G  E  A  r  G  F(„,  u)(p(u))}, 

i.e.,  those  path  descriptors  which  are  either  originated  at  v 
or  which  are  the  result  of  importing  descriptors  assigned 
by  p  to  v’s  neighbors. 

Definition  2.13.  For  X  C  TZ.  let  the  set  min(X’)  be  the 
set  of  descriptors  in  X  (for  all  destinations)  which  are 
minimally  ranked  among  the  descriptors  with  the  same 
destination,  i.e.,  define  min ( X )  = 

{rGl|Vr  dest(r')  =  dest(r)  =>  ut(r)  <  w(r/)}. 

The  assignment  p  is  a  solution  for  I  if  for  each  v  G  V  we 
have  (1)  p(y)  C  TZ}  and  (2)  p(y)  =  min(G(p,  u)). 

For  the  instance  I,  let  sol  (/)  be  set  of  solutions  for  I. 
Note  that  it  may  be  the  case  that  sol(I)  =  0. 

Running  Example,  Part  6.  The  unique  solution  ppbgp  to 
the  instance  from  part  5  of  our  running  example  is  shown 
in  Table  1 .  Note  that  the  sub-instance  obtained  by  deleting 
the  edge  {1,  5}  from  the  graph  has  two  solutions;  so,  this 
instance  is  not  robust. 

3  Examples 

We  first  discuss  two  points  in  the  design  space  that  were 
mentioned  in  the  overview  and  then  present  an  additional, 
more  complex  example. 


V 

Ppbgpiv) 

1 

{(d,  0,(1),  1,  0)} 

2 

{(d,  50,  (2,1),  1,  {red})} 

3 

{(d,  1000,  (3, 4, 5,1),  4,  {green})} 

4 

{(d,  50,  (4,5,1),  5,  {green})} 

5 

{(d,  2,  (5,1),  1,  {green})} 

Table  1:  Unique  solution  for  our  running  example. 


з. 1  Shortest-Paths  Routing 

Example  3.1.  (Shortest  Paths)  Let  TZsp  =  Vsp  x  N  x 

Seq(N).  The  second  component  of  r  G  TZsp  is  a  non¬ 
negative  length  associated  with  the  path  in  the  third  com¬ 
ponent  of  r;  this  length  is  the  sole  factor  in  path  ranking, 
with  shorter  paths  preferred.  We  permit  nodes  to  incre¬ 
ment  the  length  of  a  path  on  import  or  export,  so  that 
Lm  =  Lout  =  Lsp  where  L sp(f)  holds  iff  there  exists  a 
positive  integer  n  such  that  for  all  d  G  Vsp,  m  G  N,  P  G 
Seq(N),  we  have  /({(d,  to,  P)})  =  {(d,  m  +  n,  P)}. 
We  define  the  export  policy-application  function 
v,  /,  X)  to  produce  the  set 

{(d,  to,  uP)  |  (d,  to,  P)  G  f(X)}. 

That  is,  merely  extends  the  path  P  with  the  node 

и.  We  define  the  import  policy-application  function 
f“(u,  v,  /,  X)  to  produce  the  set 

/({r  |  r  =  (d,  l,P)  G  X  where  P  is  a  simple  path}). 

That  is  eliminates  path  descriptors  with  a  loop,  and 
then  applies  the  import  policy. 

Remark  3.2.  Note  that  by  replacing  Seq(N)  with  N 
we  could  model  “distance  vector”  protocols  similar  to 
RIP  [13].  However,  we  will  restrict  our  attention  to  those 
systems  that  do  not  allow  signaling  paths  of  arbitrary 
length. 

Example  3.3.  (Shortest-Available  Paths)  This  system  is 
a  slight  extension  of  Shortest  Paths  in  which  path  descrip¬ 
tors  can  be  filtered  out,  both  on  import  and  export.  We 
simply  modify  the  local  constraints  Lm  and  Lout  to  allow 
filtering,  leaving  all  other  definitions  unchanged.  The  new 
constraint  L sap(f)  holds  iff  there  exists  a  positive  integer 
n  such  that  for  all  d  G  VSp,  to  G  N,  P  G  Seq(N), 
either  /({(d,  to,  P)})  =  0  or  /({(d,  to,  P)})  = 
{(d,  to  +  n,  P)}. 
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3.2  A  Catalan  Example 


We  now  give  an  example  which  is  rather  unlike  traditional 
routing  problems  and  which  suggests  the  broad  applica¬ 
bility  of  the  framework  we  have  presented.  The  policy- 
application  functions  of  this  path-vector  system  ensure 
that  the  path  descriptors  which  are  passed  between  nodes 
are  those  whose  paths  are  subpaths  of  lattice  paths  related 
to  the  famous  Catalan  numbers.  We  thus  denote  this  path 
vector  system  by  PV cat-  The  set  Ucat  includes  oo,  and 
the  ranking  function  u)cat  is  constructed  so  that  exactly 
the  desired  lattice  paths  are  given  finite  rank;  subpaths  of 
the  desired  paths  are  not  filtered  but  instead  given  infinite 
rank. 

The  policies  written  by  nodes  in  an  instance  of  this 
system  do  not  affect  which  paths  are  imported  and  ex¬ 
ported;  they  only  determine  the  rank  of  the  path  descrip¬ 
tors  which  are  constrained  by  P  V  Cat  to  have  finite  rank. 
Given  the  myriad  of  combinatorial  interpretations  of  the 
Catalan  numbers,  there  are  many  ways  that  nodes  in  an  in¬ 
stance  of  PV cat  can  interpret  and  then  “naturally”  order 
the  path  descriptors  that  they  receive  from  their  neighbors. 
We  suggest  a  few  such  policies  below. 

3.2.1  The  Path  Vector  System  PVcat 

We  assume  that  each  node  in  an  instance  of  P  V  cat  has 
a  neighbor  one  step  to  the  north  and  one  step  to  the  east 
(as  though  points  with  integer  coordinates  in  R2)  and  that 
the  protocol  knows  the  spatial  relationship  between  neigh¬ 
bors. 

Let  Seq(0, 1)  be  the  set  of  all  finite  0-1  sequences,  and 
let  lZCat  =  Peat  xNxNxNx  Seq(0, 1).  We  then  make 


the  following  definitions. 

Meat 

=  NU  {00} 

destcat(d,  x,  y ,  z,  P) 

=  d 

U)Cat(d,  x,  y ,  z,  P) 

jz,  x=y 

)  00,  otherwise 

In  r  =  {d,  x,  y,  z,  P},  we  will  use  P  to  encode  the 
corresponding  path  (using  0  for  east  steps  and  1  for  north 
steps)  and  x  and  y  to  store  the  number  of  east  and  north 
steps  in  the  path. 


We  let  0Cat(X)  hold  if  and  only  if  r  G  X  => 
r  =  ( d ,  0,  0,  m,  e),  where  e  is  the  empty  se¬ 

quence.  Let  L  cat  (/)  hold  if  and  only  if  for  every  r  = 
(d,  x,  y,  z,  P)  G  Peat-  /(M)  =  {(d,  x,  y,  z' ,  P)}, 
so  that  /  may  only  change  the  fourth  element  of  the  path 
descriptor.  We  take  L  cat  to  be  the  constraint  on  both  im¬ 
port  and  export  functions. 

LSt(/)  =  L  cat(f) 

L°0t  (/)  =  L  cat(f) 

Remark  3.4.  Note  that  L  cat  ensures  that  policies  do  not 
filter  paths  as  in  Shortest  Paths  (Example  3.1).  This  could 
be  changed  to  allow  filtering  as  in  Shortest-Available 
Paths  (Example  3.3). 

We  define  the  export  policy-application  function 

t°cal{u,  v,  /,  A)  to  be  the  set 

{{d,  x  +  1,  y ,  2,  OP)  |  (d,  x ,  y,  z,  P)  G  /(A)} 
if  v  is  1  step  east  of  u,  the  set 

{(d,  x,  y  +  1,  2,  IP)  |  (d,  x,  y ,  2,  P)  G  /(A)} 

if  v  is  1  step  north  of  u,  and  0  otherwise.  Thus  t  °“t*  re¬ 
stricts  the  export  of  descriptors  to  those  neighbors  which 
are  one  step  east  or  north  from  the  exporting  node.  It  also 
updates  the  path  P,  prepending  a  0  or  1,  depending  on 
whether  this  export  is  to  the  east  or  north,  and  the  total 
number  of  east  (x)  and  north  (y)  steps  in  P.  Note  that 
we  do  not  make  assumptions  about  the  labels  of  the  nodes 
(although  we  could  express  these  restrictions  using  node 
labels  from  N  x  N).  We  define  t v,  f,  A)  to  be  the 
set 

f({(d,  x,  y,  z,  P)  G  A  \y>  x}). 

The  combination  of  t  °at  and  Peat  ensures  that  the  path 
descriptors  which  have  not  been  filtered  correspond  to 
paths  with  north  and  east  steps  and  that,  starting  at  the 
destination,  have  never  made  more  east  steps  than  north 
steps  as  they  are  forwarded.  It  is  well  known  that  the  num¬ 
ber  of  such  paths  with  exactly  n  steps  north  and  n  steps 
east  is  the  nth  Catalan  number  (2^)  The  definition 
of  Locat  means  that  the  path  descriptors  which  have  finite 
rank  are  exactly  those  which  have  passed  along  equally 
many  north  and  east  steps.  While  PV cat  determines  the 
set  of  descriptors  which  are  assigned  finite  rank  at  each 
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node,  it  has  no  impact  on  the  ordering  of  the  descriptors  in 
this  set.  These  rankings  will  be  determined  by  the  policies 
of  nodes  in  an  instance  of  PV  CQt  and  may  correspond  to 
natural  orderings  on  some  of  the  many  families  of  objects 
counted  by  the  Catalan  numbers  (66  examples  of  which 
are  given  in  Exercise  6.19  of  [24]). 

3.2.2  Policies  for  PVcat 

Assume  that  we  have  some  policy  language  PLcat  for 
PVCat  in  which  a  node  can  describe:  a  family  of  objects 
counted  by  the  Catalan  numbers;  a  ranking  of  these  ob¬ 
jects;  and  an  appropriate  bijection  between  the  objects  and 
Catalan  sequences.  (A  Catalan  sequence  of  size  n  is  an 
element  of  Seq(0, 1)  with  n  Os  and  n  Is,  such  that  no  ini¬ 
tial  subsequence  has  more  Os  than  Is.)  We  now  consider 
different  policy  functions,  compiled  from  policies  writ¬ 
ten  in  PL  cat  and  which  satisfy  L  cot,  which  may  arise  in 
PVcat-  These  functions  must  be  of  the  form 

f({d,  x,  y,  z,  P})  =  {(d,  x,  y ,  z\  P)}, 

so  we  will  define  the  functions  below  by  defining  z'  in 
each  instance. 

The  first  two  examples  use  as  objects  lattice  paths  (i.e., 
composed  of  the  steps  (1,0)  and  (0,1))  from  (0,0)  to 
(n,  n)  which  never  fall  below  the  diagonal  y  —  x.  They 
also  use  the  bijection  described  in  the  definition  of  PV  cat 
in  which  a  1  appearing  in  an  element  of  Seq(0, 1)  corre¬ 
sponds  to  a  step  of  (0, 1)  in  a  lattice  path.  For  the  first 
example,  let  the  ranking  of  a  path  be  its  area,  i.e.,  the 
number  of  whole  squares  below  the  path  and  above  the 
diagonal  y  =  x.  The  import  function  then  sets  z '  to  be  the 
area  of  the  path  corresponding  to  P.  For  our  second  ex¬ 
ample,  we  prefer  shorter  paths  to  longer  ones,  and  given 
two  paths  of  the  same  length,  we  prefer  the  one  which 
has  the  (1, 0)  step  at  the  first  step  where  they  differ.  For 
a  sequence  P  of  length  2 n,  the  import  function  then  sets 
z'  to  be  Ci) /(*  +  1)  plus  the  number  of  paths  of 

length  2n  that  have  a  (1,0)  step  in  the  first  place  where 
they  differ  from  P. 

Among  all  paths  of  length  2 n,  the  path  along  the  di¬ 
agonal  (alternating  north  and  east  steps)  will  be  the  most 
preferred  using  both  of  these  policies,  while  the  path  con¬ 
sisting  of  n  steps  north  followed  by  n  steps  east  will  be 
the  least  preferred.  However,  the  first  policy  will  prefer 
any  path  along  the  diagonal  to  any  other  path,  regardless 


of  the  lengths  of  the  two  paths,  in  contrast  to  the  second 
policy.  They  will  also  disagree  on  the  relative  rankings 
of  the  two  paths  encoded  by  Pi  =  1011111 .. .  00000  . . . 
andP2  =  110010101010.... 

Policies  might  also  be  written  which  view  the  object 
encoded  by  a  sequence  P  of  length  2 n  as  an  ordering  n 
of  {1, , . . ,  n}  which  does  not  have  three  (possibly  non- 
adjacent)  elements  in  decreasing  order  (a  321-avoiding 
permutation).  (See  [24]  for  a  bijection  to  the  lattice  paths 
we  have  been  considering.)  The  import  function  could  as¬ 
sign  to  z'  any  number  of  values,  including  various  permu¬ 
tation  statistics  (e.g.,  descents,  inversions)  evaluated  on  tt. 
Once  the  path  P  is  viewed  as  a  permutation,  there  are  a 
wide  variety  of  ways  to  define  z. 

4  Expressiveness 

To  rigorously  capture  the  expressive  power  of  path-vector 
systems,  we  use  a  variant  of  the  Stable  Paths  Problem 
(SPP)  [9]  as  a  sematic  domain.  After  reviewing  the  SPP 
framework,  we  show  how  to  map  path-vector  instances  to 
equivalence  classes  of  SPP  instances  and  use  this  to  com¬ 
pare  the  expressiveness  of  path-vector  policy  systems. 

4.1  The  Stable  Paths  Problem  (SPP) 

Definition  4.1.  The  quadruple 

5  =  (G,  vo,  V ,  A) 

is  an  instance  of  the  Stable  Paths  Problem  (SPP)  if  G  = 
(V,  E)  is  a  finite  undirected  graph,  Vq  £  V  (called  the 
origin),  V  is  a  set  of  simple  paths  in  G  terminating  at  Vo, 
and  the  mapping  A  takes  nodes  v  £  V  to  a  path  ranking 
function  A"  =  A(u).  Each  Xv  is  a  function  that  takes  a 
path  in  Vv  —  {P  £  V  \  P  is  a  path  starting  at  v}  to  its 
rank  in  N.  If  W  C  Pv,  then  the  subset  of  “best  paths”  in 
W,  m  in  (A",  W)  C  W,  is  defined  as  the  set 

{P  £  W  |  for  every  P'  £  W,  A V(P)  <  A V(P')}. 

Definition  4.2.  A  path  assignment  for  an  SPP-instance  S 
is  any  mapping  tt  from  V  to  subsets  of  V  such  that  tt(v)  C 
Vv .  The  set  candidates(rt,  7r)  consists  of  all  permitted 
paths  at  u  that  can  be  formed  by  extending  the  paths  as¬ 
signed  to  neighbors  of  u.  For  u  =  vq,  candidates(u,  tt)  = 


12 


{(it)},  and  for  u  f  vq,  candidates(u,  tt)  equals 

{uQ  G  Vu  |  {u,  it}  G  E  and  Q  =  7r(v)}. 

A  path  assignment  7r  is  a  solution  for  an  SPP  if  for  ev¬ 
ery  node  u  we  have  tt(u)  =  min(A“,  candidates(u,  7r)). 
That  is,  if  F  is  a  functional  that  takes  path  assignments 
7T  to  path  assignments  F(tt),  defined  as  F(ir)(u)  = 
min(A“,  candidates(u,  7r)),  then  the  solutions  of  the  SPP 
are  exactly  the  fixed  points  of  F  (for  any  solution  n  we 
have  F(tr)  =  it,  and  F(tt)  =  7r  implies  7r  is  a  solution). 

A  convenient  abbreviation  for  the  best  path  at  u  under  7r 
is  defined  to  be  best(u,  7r)  =  min(AM,  candidates  (it,  7r)). 
Then  7r  is  a  solution  if  tt(u)  =  best(it,  7r)  at  each  node  u. 

Remark  4.3.  The  definition  for  SPP  given  here  is  a  bit 
more  general  than  that  of  [9]  in  that  we  do  not  require 
“strictness,”  which  guarantees  that  1 7r  0)1  <  1  for  every 
solution  tt.  In  addition,  we  have  changed  the  order  of  the 
ranking  to  prefer  paths  with  smaller  (not  larger)  rank.  Fi¬ 
nally,  we  have  allowed  any  node  vq  G  V  to  be  the  origin. 


two  distinct  signaling  paths  may  result  in  the  same  path 
descriptor.  Or,  it  may  be  the  case  that  r i  =  r(Pi,  rw)  f 
r{P2,  rw)  =  r2,  but  w(n)  =  w(r2). 

There  is  an  exact  correspondence  between  the  set  of 
solutions  for  I  and  the  set  of  solutions  for  S(I)  as  shown 
by  the  following  theorems.  (The  proofs  are  mostly  al¬ 
gebraic  manipulation  using  the  definitions  above  and  we 
defer  them  to  Appendix  A.) 

Theorem  4.5.  If  tt  is  a  solution  for  SutWtrwy  then 

Pi r(v)  =  [J  r(P,  rw) 

PGt t(v) 

is  a  solution  for  I(w,  rw). 

Theorem  4.6.  If  p  is  a  solution  for  I  (w,  rw),  then 
TtP{v)  =  {P  G  Pv  |  r(P,  rw)  C  p{v)} 
is  a  solution  for  S(itW<rwy 


4.2  Mapping  Path-Vector  Systems 
to  SPP  Instances 

Suppose  that  /  =  (G(V,E),  F)  is  an  instance  of  some 
(PV,  PL).  We  may  represent  I  as  a  set  of  instances  of 
the  Stable  Paths  Problem  (SPP).  For  each  w  G  V  and  each 
rw  G  Fon9(w)  we  construct  an  SPP  instance  S(x.w,rw)- 

Definition  4.4.  Define  I(w,  rw)  to  be  a  restriction  of 
instance  I  where  the  only  descriptor  originated  is  rw  at 
node  w.  Given  / (tv,  rw ) ,  define  the  corresponding  SPP 
instance  S(itWtJ.w)  as  described  below,  and  let  S(I)  = 
{I(w,  rw)  |  w  G  V,  rw  G  Fon9(w)}  be  the  set  of  all 
SPP  instances  which  correspond  to  a  restriction  of  I. 

Let  the  set  of  permitted  paths  in  S'(/!W;T.ti))  be 
P(i,w,rw )  =  {P  I  r(P,  rw)  ^  0}.  For  each  v  G  V, 
set  the  values  of  the  ranking  function  A  L  w  r  ^  such  that 
the  following  holds:  A^  ^Pi)  <  A v(I^rw)(P2)  if 
and  only  if  {iq}  =  r(Pi,  rw),  {r2}  =  r(P2,  rw),  and 
w(fi)  <  w(r2). 


Theorem  4.7.  7rPir  =  tt  and  =  p. 


Running  Example,  Part  7.  An  SPP  corresponding  to  our 
running  example  is  presented  in  Figure  4.  Node  1  is  the 
origin.  Next  to  each  node  are  the  permitted  paths  of  that 
node  listed  in  order  of  preference,  starting  with  the  most 
preferred  at  the  top.  Note  that  the  actual  values  of  the 
ranking  function  are  not  important,  only  the  relative  pref¬ 
erence  of  each  permitted  path  at  each  node;  this  figure  can 
be  taken  to  represent  an  entire  equivalence  class  of  SPPs 
with  different  values  for  each  A1’  but  the  same  orderings 
on  each  set  Vv . 


23  1 
234  1 
2  1 
25  1 


5  1 
52  1 


3  25  1 
345  1 
34  1 

3  1 


45  1 
43  25  1 
43  1 
4  1 


It  may  be  that  AL  ,  (Pi)  =  A  A  JP2)  for  paths 

Pi  if  P2.  This  can  happen  in  one  of  two  ways.  First,  it  Figure  4.  SPP  for  running  example, 

may  be  the  case  that  r(Pi,  rw)  =  r(P2,  rw).  That  is. 
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4.3  Definition  of  Expressive  Power 

Two  distinct  SPPs  can  represent  the  same  set  of  solutions 
because  the  specific  values  in  N  that  a  ranking  function 
A1’  takes  on  are  not  really  important — what  is  important  is 
the  relationship  between  the  rankings  of  permitted  paths 
at  a  given  node  v. 

For  any  SPP  instance  S,  define  two  relations,  ©  5  and 
0S,  on  permitted  paths  V.  First,  P\  Qs  P2  if  and  only  if 
Pi,  P2  £  V  and  Pi  is  a  subpath  of  P2,  i.e.,  there  exists 
a  path  Q  (possibly  e,  the  empty  path)  such  that  QP\  = 
P2.  Note  that  © s  is  a  partial  order  on  permitted  paths. 
Second,  Pi  0s  P2  if  and  only  if  there  is  a  v  £  V  such  that 
Pi,  P2  G  Vv  and  A1’ (Pi)  <  A V(P2).  Define  relation  ©5 
to  be  the  transitive  closure  of  the  relation  0s  U  0g. 

Definition  4.8.  We  say  that  two  SPPs  Si  and  S2  are 
equivalent  if  they  are  defined  on  the  same  graph,  have  the 
same  set  of  permitted  paths,  and  ©Si  =  0s2-  Define  the 
set  £  ( S )  to  be  the  set  of  all  SPPs  equivalent  to  S. 

Definition  4.9.  We  define  the  expressive  power  of 
a  path- vector  policy  system  ( PV ,  PL)  as  the  set 
M(PV,  PL)  = 

{£(S)  |  S  £  S(I)  for  some  (PV,  PL)  instance  I}. 

A i(PV)  means  the  maximal  expressive  power  of  PV 
when  it  is  not  constrained  by  a  policy  language,  i.e.,  the 
maximal  expressive  power  of  PV  with  respect  to  a  pol¬ 
icy  language  allowing  all  legal  policy  functions  to  be  ex¬ 
pressed. 

Remark  4.10.  We  note  that 

M(PVsp)  C  M(PV sap)  C  M(PVpbgp). 

Shortest-Available  Paths  (PV sap)  allows  nodes  to  filter 
routes  while  Shortest  Paths  (PV sp)  does  not.  Any  rout¬ 
ing  configuration  in  PV sp  is  captured  by  PV sap.  But, 
given  any  configuration  permitted  in  PV  sp,  we  can  filter 
one  of  the  routes  and  obtain  a  new  configuration  where 
the  policies  are  permitted  by  PV sap  but  not  PV sp;  thus, 
M(PV sp)  C  M(PV sap).  Likewise,  because  PV pbgp 
essentially  allows  nodes  to  rank  routes  in  any  order,  it  per¬ 
mits  a  routing  configuration  where  a  node  prefers  a  longer 
path  to  a  shorter  one.  Therefore  its  expressive  power  is 
more  than  that  of  PV sap. 


5  Robustness 

We  first  define  robustness  using  SPP  semantics  and  then 
present  a  natural  class  of  expressive,  robust  SPPs,  charac¬ 
terizing  this  class  in  the  path-vector  framework. 

5.1  Definition  of  Robustness 

Definition  5.1.  An  instance  I  over  (PV,  PL)  is  said  to  be 
robust  if  it  has  a  unique  solution  and  every  sub-instance  of 
I  has  a  unique  solution.  If  every  instance  of  a  path-vector 
policy  system  (PV ,  PL)  is  robust,  then  (PV ,  PL)  is  said 
to  be  robust. 

Definition  5.2.  In  a  similar  manner,  we  can  define  robust¬ 
ness  of  SPP  instances.  Define  the  set  1ZSVV  as 

1ZSVV  =  {£ (S)  |  S  is  a  robust  SPP  instance}. 

Given  the  results  of  the  previous  section,  we  then  see 
that  a  path-vector  policy  system  (PV,  PL)  is  robust  if 
and  only  if 

M(PV ,  PL)  c  nsvv. 

We  are  interested  in  the  design  space  of  robust  path-vector 
policy  systems. 

Conjecture  5.3.  For  every  (PV ,  PL),  ifM(PV,  PL)  C 
1ZSVV,  then  there  exists  an  £(S)  £  1ZSVP  such  that 
£(S)  A4(PV,  PL).  In  other  words,  no  path-vector 
policy  system  can  capture  exactly  all  robust  systems. 

5.2  A  Natural  Set  of  Robust  Systems 

Definition  5.4.  The  SPP  S  is  almost-partially  ordered  if 
©S  is  reflexive,  transitive,  and  obeys  the  following  rule: 

Rule  5.5.  Pi  0 s  P2  and  ©2  Qs  ©1  implies  that  Pi  =  P2 
or  3  v  such  that  Pi,  P2  £VV. 

(Traditional  notions  of  antisymmetry  and  partial  order¬ 
ing  for  0s  do  not  allow  permitted  paths  of  equal  rank  at 
any  node;  thus,  we  use  the  slightly  modified  notion  given 
above.)  Then  let 

AVOSPV  =  {£ (S)  |  S  is  almost-partially  ordered} 

be  the  set  of  all  almost-partially  ordered  equivalence 
classes  of  SPPs. 
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If  the  SPP  S  is  almost-partially  ordered,  then  we  will 
write  Pi  <  P2  for  I\  Qs  P2,  and  we  will  write  Pi  <  P2 

if  Pi  ©s  Pi  but  Pi  0  s  Pi- 

Theorem  5.6.  If  an  SPP  instance  S  is  almost-partially 
ordered,  then  it  is  robust. 

In  order  to  prove  Theorem  5.6,  we  must  introduce  an¬ 
other  definition  from  the  SPP  framework  [9], 

Definition  5.7.  A  dispute  wheel  is  a  cycle  of  nodes 
Vi,V2,  ■  ■  ■  ,Vk,Vk+i  =  Vi  in  an  SPP  instance  such 
that  there  exist  paths  Ri,  R2, . . . ,  Rk,  Rk+i  =  Ri  and 
Qi,Qi,- ■  ■  ,Qk,Qk+i  =  Q 1  such  that  Qt  G  VVi, 
PIQI+ 1  G  Vv\  and  XVi  (RiQi+i)  <  AVi{Qi).  The  nodes 
and  paths  Ri  are  on  the  rim  of  the  dispute  wheel,  while 
the  paths  Qi  are  called  the  spokes  of  the  wheel. 

The  following  lemma  connecting  dispute  wheels  and 
Definition  5.4  will  be  useful  in  proving  Theorem  5.6. 

Lemma  5.8.  The  SPP  S  is  almost-partially  ordered  if  and 
only  if  it  has  no  dispute  wheel. 

Proof.  First,  suppose  that  S  is  almost-partially  ordered. 
Furthermore,  suppose  that  S  has  a  dispute  wheel  with 
Ri,Qi  as  in  Definition  5.7  Because  AUi(Qi-,%)  < 
A Ui(RiQi),  we  know  that  RiQi  <  Qi-i  because  <  sub¬ 
sumes  relation  0g.  And  because  Qi  is  a  subpath  of  RiQi , 
we  know  that  Qi  <  RiQi.  Therefore,  Qi  <  0,  -1  •  Fol¬ 
lowing  this  chain  of  inequalities  around  the  dispute  wheel 
yields  the  contradiction  Qi  <  Qi.  Therefore,  S  has  no 
dispute  wheel. 

For  the  other  direction,  suppose  that  S  has  no  dispute 
wheel  and  also  assume  that  S  is  not  almost-partially  or¬ 
dered.  If  S  is  not  almost-partially  ordered,  then  there  must 
exist  paths  Pi  and  P2  that  violate  Rule  5.5  because  the  re¬ 
lation  ©s  is  inherently  reflexive  and  transitive;  i.e., 

3  Pi  f  P2  such  that 

(i)  Pi  Qs  Pi, 

(ii)  Pi  Qs  Pi,  and 

(iii)  fv^v--{Pi,Pi}<tVv 

Conditions  (i)  and  (ii)  imply  that  there  exist  sets  of  paths 
{Yi}  and  { Zj } ,  not  necessarily  distinct,  such  that 

Pi  =  YiQsY20s  ■■■  Qs  Yu-i  Qs  Yn  =  P2 


and 

Pi  =  ZiQs  Z2&s  ■  ■  ■  Qs  Zn- 1  0s  Zn  =  Pi, 

respectively.  From  (iii)  we  know  that  it  is  not  the  case  that 
Pi  Qs  Pi  or  that  P2  Qs  Pi,  if  Pi  Qs  Pi  and  Pi  Qs  Pi 
then  Pi  =  P2,  which  is  not  possible  if  Pi  and  P2  vi¬ 
olate  Rule  5.5.  Therefore,  there  must  be  intervening 
distinct  paths  in  the  cycle  of  relationships  above,  i.e., 
({Yj}  U  {Zj})\{Pi,  P2}  7^  0.  Using  the  “cycle  of  paths” 
in  {Yi}U{Zj},  we  can  build  a  dispute  wheel:  if  Xi  QsX2 
for  Xi,X2  G  {Yi}  U  [Zjj,  then  X±  is  a  subpath  of  X2 
and  X\  can  be  a  spoke  path  while  X2  can  be  the  spoke 
path  Xi  exported  to  a  rim  neighbor;  then  X2  Qs  X3  and 
X2  is  the  rim  path  preferred  to  the  spoke  path  X  :i,  etc. 

The  existence  of  a  dispute  wheel  in  S'  is  a  contradiction; 
thus  S  is  almost-partially  ordered.  □ 

With  Lemma  5.8  in  hand  and  a  result  from  [9],  we  can 
proceed  with  the  proof  of  Theorem  5.6. 

Proof.  If  S  is  almost-partially  ordered,  then  by 
Lemma  5.8  it  has  no  dispute  wheel.  Then  by  Theo¬ 
rem  V.10  in  [9],  S  is  robust.  (In  particular.  Theorem  V.3 
in  [9]  states  that  a  dispute-wheel-free  S  has  a  solution. 
Theorem  V.4  states  that  it  has  a  unique  solution.  The¬ 
orem  V.9  guarantees  that  the  SPVP  algorithm  from  [9] 
will  converge  to  a  solution  for  S,  and  Theorem  V.10 
guarantees  that  a  unique  solution  can  be  found  in  the 
presence  of  link  and  node  failures.)  □ 

Remark  5.9.  An  alternative  proof  may  be  possible  us¬ 
ing  fixed  point  theory.  As  remarked  in  Definition  4.2,  the 
solutions  of  the  SPP  are  exactly  the  fixed  points  of  F,  be¬ 
cause  F(ir)  =  7r  implies  n  is  a  solution,  and  for  any  solu¬ 
tion  7 r  we  have  F{ n)  =  7 r.  Perhaps  there  is  some  relation 
that  we  can  impose  on  the  function  space  of  path  assign¬ 
ments  so  that  if  S  is  almost  partially  ordered,  then:  (1) 
this  relation  is  partially  ordered;  (2)  F  is  monotonically 
increasing;  and  (3)  F  is  continuous  with  respect  to  this 
order.  Then  the  above  proof  could  dispense  with  dispute 
wheels  and  instead  use  standard  fixed  point  theorems. 

Theorem  5.10.  If  A4(PV ,  PL)  C  APOSPV,  then  the 
path-vector  policy  system  {PV ,  PL)  is  robust. 

Proof.  This  follows  from  Theorem  5.6.  □ 
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Remark  5.11.  The  above  theorems  give  the  broadest- 
known  sufficient  condition  for  robustness  and  are  consis¬ 
tent  with  the  results  in  [9] . 

5.3  Increasing  Path-Vector  Systems 
Definition  5.12.  The  SPP  instance  S  is  increasing  if 
A U(Q)  <  A v(vQ) 

for  all  edges  {it,  u}  with  path  Q  permitted  at  u  and  path 
vQ  permitted  at  v.  (We  are  comparing  the  rankings  as¬ 
signed  by  different  nodes;  these  values  have  no  a  priori 
relationship.)  Let 

TSVV  =  {£ (S)  |  S  is  increasing} 

be  the  set  of  all  increasing  equivalence  classes  of  SPPs. 

Theorem  5.13.  AVOSVV  =  TSVV. 

Proof.  Clearly  XSW  C  AVOSVV  because  if  the  SPP 
S  is  increasing,  its  preferences  are  already  consistent  with 
the  subpath  relation  so  that  Qs  is  an  almost-partial  or¬ 
der;  so,  we  only  need  to  show  that  AVOSVV  C  TSVV. 
If  S  is  an  SPP  such  that  £(S)  €  AVOSVV ,  then  we 
can  topologically  sort  the  permitted  paths  of  S.  (See  Ap¬ 
pendix  B  for  details  of  this  process.)  We  can  then  cre¬ 
ate  a  new  SPP  S'  by  creating  a  new  ranking  function  A' 
which  both  respects  this  topological  order  (so  that  the  sys¬ 
tem  is  increasing)  and  which  has  the  same  relative  prefer¬ 
ences  as  A.  Clearly  £(S)  =  £(S');  as  S'  is  increasing, 
£(S)  G  TSVV.  □ 

Ideally,  we  would  like  to  construct  a  (PL,  PL)  pair 
such  that  Ad  (PL,  PL)  =  TSVV,  thus  obtaining  expres¬ 
siveness  and  robustness.  We  now  examine  two  ways  to 
modify  the  running-example  system  PL ^bgp  so  that  the 
result  is  an  increasing  path-vector  system.  As  we  see  in 
the  next  section,  each  of  these  systems  lacks  some  de¬ 
sirable  property,  a  conflict  which  is  in  fact  unavoidable 
(Theorem  6.9). 

Example  5.14.  System  PL up  shares  local  preferences 
between  nodes  (therefore,  it  is  not  policy-opaque)  and  has 
local  policy  constraints  that  enforce  increasing  rank  be¬ 
tween  neighbors.  Modify  the  definition  of  t out  so  that  the 
local-preference  value  is  passed  between  neighbors: 

Ktiui  L  />  x)  =  {  (d,  to,  uP ,  u ) 

j  (d,  m,  P,  x )  G  f(X)}. 


Let  the  export  constraint  be 

L™‘(/)^Vr,  W({r} )<w(/({r») 
and  let  the  import  constraint  be 

Llp(/)«Vr,  w(M)  <w(/({r»). 

That  is,  we  constrain  the  legal  policies  to  be  those  that 
increase  path  rank;  in  theory,  such  policies  can  be  written 
because  nodes  have  access  to  neighbors’  local-preference 
values. 

Example  5.15.  System  P  L /orce  modifies  both  protocol 
transformations  so  that  they  filter  out  descriptors  whose 
rank  does  not  increase  under  the  application  of  the  policy 
function  in  question.  If  r  =  (d,  l,  P,  n)  G  X,  define 

h(r)  =  (d,  0,  P,  n).  Then  let  tl^rce(u,  v,  /,  X)  be  the 

set 

{/({/i(r)})  |  r  G  X  describes  a  simple  path 
and  cu({?’})  <  u>(f({h(r)}))} 

and  let  t'fffju,  v,  f,  X)  be  the  set 

{(d,  l ,  uP,  u)\r=  ( d ,  l ,  P,  x)  G  f(X) 
and cu({r})  <  w(/({r}))}. 

Remark  5.16.  M(PV up)  =  M{PV }orce)  =  TSVV. 

6  Autonomy,  Transparency,  and 
Policy  Opaqueness 

6.1  Autonomy 

Network  operators  often  require  a  high  degree  of  auton¬ 
omy  when  defining  routing  policies,  i.  e. ,  they  want  wide 
latitude  to  write  policies  that  reflect  their  own  interests. 

We  first  define  a  general  notion  of  autonomy.  A  col¬ 
lection  of  predicates  on  path  descriptors,  such  that  exactly 
one  predicate  holds  for  each  descriptor  in  1Z,  induces  a 
partition  II  of  1Z.  A  partial  order  on  these  predicates  in¬ 
duces  a  partial  order  on  1Z.  A  path- vector  policy  system  is 
autonomous  with  respect  to  (II,  <n)  if  there  exists  a  legal 
policy  that  ranks  routes  consistent  with  the  partial  order 
on  II  induced  by  <n- 

For  example,  a  policy  writer  may  wish  to  rank  routes 
solely  as  a  function  of  the  value  of  one  particular  attribute 
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of  descriptors  in  the  system.  If  he  or  she  is  to  do  so  with 
full  freedom,  the  system  must  be  autonomous  with  respect 
to  every  partial  ordering  of  the  collection  of  predicates 
which  test  the  value  of  that  attribute.  A  system  without 
this  autonomy  may  have  local-policy  constraints  prevent¬ 
ing  the  desired  policy  configuration.)  We  can  say  that 
the  space  of  ordered  partitions  given  which  a  path-vector 
policy  system  is  autonomous  represents  the  autonomy  of 
the  system,  and  that  full  autonomy  is  reached  when  pol¬ 
icy  writers  can  write  policies  consistent  with  all  possible 
partitions. 

Formally,  we  have  the  following. 

Definition  6.1.  A  path-vector  system  PV  is  autonomous 
with  respect  to  partition  II  of  X  C  TZ  iff  for  any  partial  or¬ 
der  <n  on  the  partition,  there  exists  a  legal  import  policy 
f  (i.e.,  L *"(/)  holds)  such  that  for  all  i\  £  Hi,Tj  £  IF,- 
with  11,  <jr  IF,,  there  exist  f , ,  fj  £  TZ  such  that 

(f(n)  =  fi  and  f(rj)  =  fj )  =>  w(f;)  <  u(fj). 

Useful  partition  types,  as  described  above,  include  par¬ 
titions  based  on  attributes,  e.g.,  “Let  r  £  1 1 ,  C  TZ  ill 
A(r )  =  i”  (the  index  set  of  the  partition  is  the  set  of  pos¬ 
sible  attribute  values  A(r)).  If  PV  is  autonomous  with 
respect  to  such  a  partition,  we  will  say  that  PV  is  au¬ 
tonomous  with  respect  to  A. 

Remark  6.2.  If  PV  is  autonomous  with  respect  to  A  and 
B  together  (i.e.,  “Let  r  £  II C  7 Z  iff  A(r)  =  i  and 
B(r )  =  j”),  then  PL  is  both  autonomous  with  respect 
to  A  and  autonomous  with  respect  to  B.  The  converse  of 
this  is  not  true. 

Definition  6.3.  The  autonomy  of  a  path-vector  system 
PV  is 

A(PV)  =  {II  |  PL  is  autonomous  with  respect  to  11} 

One  intuitive  definition  for  the  concept  of  full  auton¬ 
omy  might  be  that  P  V  is  autonomous  with  respect  to  all 
possible  predicates  II.  However,  this  is  not  reachable.  To 
give  a  more  useful  definition,  we  first  introduce  the  fol¬ 
lowing  concept. 

Definition  6.4.  Q(r,  v)  is  an  importability  predicate  iff 
Q(r ,  v)  holds  if  tm  applies  some  Fm(v,u)  to  r  £  X  C 

TZ. 


Definition  6.5.  P  V  has  full  autonomy  iff  there  exists  a 
PL  such  that  for  all  instances  /  over  (PV,  PL)  and  all 
vertices  v  in  the  instance  graph  there  exists  an  importa¬ 
bility  predicate  Imp(r,  v)  such  that  for  all  partitions  n  of 
{r  £  TZ  |  Imp(r,  v)},  PV  is  autonomous  with  respect  to 

n. 

This  definition  of  full  autonomy  is  more  reasonable  be¬ 
cause  it  includes  node  independence  and  limits  the  scope 
of  path  descriptors  considered  to  those  that  are  actually 
imported  at  a  given  node.  Informally  then,  a  path-vector 
system  has  full  autonomy  when  imported  path  descriptors 
can  be  ranked  freely  at  every  node. 

We  now  define  a  more  specific  notion  of  autonomy  suit¬ 
able  for  BGP-like  systems.  It  describes  the  ability  to  clas¬ 
sify  neighbors,  e.g.,  so  that  an  ISP  can  prefer  routes  from 
customers  over  routes  from  peers. 

Definition  6.6.  The  path- vector  policy  system  (PV,  PL) 
supports  autonomy  of  neighbor  ranking  if,  for  every  in¬ 
stance  I,  node  v,  and  a  partition  C\,  Cf, ....  Cf-  of  the 
set  of  neighbors  of  v,  there  exists  a  legal  import  policy  at 
v  that  does  not  filter  routes  such  that,  for  1  <  j  <  k  -  1, 
v  always  prefers  routes  sent  from  partition  C j  over  those 
sent  from  partition  Cj+ 1 . 

Note  that  autonomy  of  neighbor  ranking  is  simply  au¬ 
tonomy  with  respect  to  a  partition  on  the  value  of  the 
next  hop  (or  path  vector)  attribute  of  “importable”  path 
descriptors. 

The  system  PV up  in  Example  5.14  does  not  sup¬ 
port  autonomy  of  neighbor  ranking.  However  the  sys¬ 
tem  PV force  in  Example  5.15  does,  but  in  what  might 
be  called  a  draconian  manner,  i.e.,  the  policy-application 
functions  enforce  increasing  rank  even  if  the  policy 
writer’s  policies  do  not — routes  that  are  not  increasing  in 
rank  are  simply  filtered  out  by  the  protocol  (not  the  poli¬ 
cies). 

6.2  Protocol  Transparency 

This  brings  us  to  another  important  property  for  policy 
writers:  they  should  be  able  to  easily  understand  the  se¬ 
mantics  of  policies  that  they  write.  For  example,  the 
import-policy  application  Y  =  tm(v,  u,  f,  X)  is  de¬ 
fined  with  the  user-supplied  policy  /  as  input,  but  there  is 
no  guarantee  that  the  policy  writer  can  easily  understand 
why  the  output  Y  is  obtained. 
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Definition  6.7.  Suppose  there  exists  a  function  tm 
whose  definition  does  not  depend  on  /,  such  that 
tin( v,  u,  f,  X)  =  f(iin(v,  u,  X)).  Then  PV  is 
said  to  apply  import  policies  transparently.  Similarly,  if 
there  exists  a  function  tout  such  that  tout(v,  u,  f,  X)  = 
tout(v,  u,  f(X)),  then  PV  is  said  to  apply  export  poli¬ 
cies  transparently.  If  both  of  these  conditions  hold,  then 
PV  is  transparent.  In  this  case,  we  can  define  the  func¬ 
tion  t(v,  u,  X)  =  tm(v,  u,  iout(u ,  v,  X))  and  note 
that 

F{v,  u)(X)  =  Fin(v,  u)(t(v,  u,  Fout(u,  v)(X))). 

That  is,  the  transformation  between  two  neighboring 
nodes  participating  in  P  V  can  be  easily  understood  as  the 
composition  of  three  functions:  the  export  policy  at  one 
node;  a  fixed,  uniform  transformation  t  given  by  P  T ;  and 
the  import  policy  at  another  node. 

Remark  6.8.  The  system  P  V force  is  not  transparent,  but 
the  systems  PVup  and  PV pbgp  are. 

6.3  A  Design  Trade-off 

We  saw  that  the  systems  PV  up  and  PV  force  are  both  ro¬ 
bust,  yet  one  supports  autonomy  of  neighbor  ranking  but 
is  not  transparent  while  the  other  is  transparent  but  does 
not  support  autonomy  of  neighbor  ranking.  This  is  just 
one  example  of  a  more  general  design  trade-off: 

Theorem  6.9.  If  (PV ,  PL)  is  any  path-vector  policy 
system  with  A4(PV,  PL)  =  AVOSW,  then  either 
(PV,  PL)  does  not  support  autonomy  of  neighbor  rank¬ 
ing  or  PV  is  not  transparent,  or  both. 

Proof.  The  SPP  instance  GOOD  GADGET  in  Figure  5(a) 
is  in  AVOSW,  so  it  must  be  expressible  by  some 
(PV ,  PL)  instance.  If  (PV,  PL)  supports  autonomy 
of  neighbor  ranking,  then  node  2  can  change  its  policies 
to  prefer  paths  through  node  3,  producing  the  SPP  in¬ 
stance  BAD  GADGET  in  Figure  5(b)  which  has  no  solu¬ 
tion.  Therefore,  because  M. (PV,  PL)  =  AVOSW, 
the  policy-application  functions  of  PV  must  not  allow 
this  policy  to  take  effect,  i.e.,  the  system  is  not  transpar¬ 
ent.  □ 


(a)  (b) 


Figure  5:  (a)  The  SPP  GOOD  GADGET  and  its  unique  so¬ 
lution.  (b)  The  SPP  BAD  GADGET. 

6.4  Policy  Opaqueness 

Policy  writers  might  often  think  of  autonomy  and  trans¬ 
parency  in  terms  of  path-descriptor  attributes.  In  partic¬ 
ular,  a  policy  writer  might  be  concerned  with  what  free¬ 
dom  he  or  she  has  to  change  a  path-descriptor  attribute 
and  what  effect  such  a  change  might  have.  A  related  con¬ 
cern,  the  property  of  policy  opaqueness  that  we  discuss  in 
this  section,  is  whether  attribute  settings  are  shared  with 
neighbors  or  kept  private.  On  one  hand,  the  exchange 
of  information  might  be  important  to  allow  policy  writ¬ 
ers  to  make  important  conditional  assignments  that  affect 
ranking  or  the  overall  robustness  of  the  system;  on  the 
other  hand,  policy  writers  may  not  want  to  disclose  their 
changes  to  path-descriptor  settings  (especially  when  these 
changes  should  not  influence  others). 

Informally,  an  opaque  system  is  one  where  policy- 
related  attributes  are  kept  hidden  when  path  descriptors 
are  exchanged  between  nodes.  It  is  expected  that  this  “in¬ 
formation  hiding”  occurs  in  the  protocol  transform  func¬ 
tions  (specifically  tout,  because  we  expect  tm  to  be  ex¬ 
ecuted  by  a  router  that  is  different  than  the  one  that  last 
set  attribute  values)  as  a  built-in  transformation  to  the 
path  descriptor.  So  that  we  may  conveniently  discuss  the 
opaqueness  of  a  system  in  terms  of  which  attributes  are 
shared  and  which  are  kept  private,  we  make  the  following 
definition.  Let  r~A  be  the  path  descriptor  r  with  attribute 
A  removed. 

Definition  6.10.  Attribute  A  is  opaque  iff,  for  any  two 
r'i .  V‘2  £  1Z,  rfA  =  rfA  implies  that 

tout  (v,  u,  Fout(v,  u),  {n})  =  tout  (v,  u,  Fout(v,  u),  {r2}) 
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for  all  v,  u  (i.e.,  either  r±  and  r'2  are  both  filtered  or  they 
produce  the  same  descriptor). 

An  opaque  attribute,  then,  is  one  that  is  essentially 
cleared  on  export  (after  application  of  t out). 

Remark  6.11.  The  local-preference  attribute  is  opaque  in 
the  systems  PV force  and  PV Plbgp,  but  not  in  the  system 
PV up.  In  this  case,  the  opaqueness  of  local-preference 
and  autonomy  of  neighbor  ranking  are  closely  intertwined 
because  adjusting  rank  for  next-hop  involves  adjusting  the 
local-preference  value  accordingly;  this  is  not  arbitrarily 
permitted  in  PV up.  It  is  the  implementation  of  ranking 
restrictions  in  PVup  that  removes  the  opaqueness  of  lo¬ 
cal  preference.  It  is  not  generally  true  that  loss  of  auton¬ 
omy  of  neighbor  ranking  goes  hand-in-hand  with  a  loss  of 
opaqueness. 

7  Global  Constraints 

Theorem  6.9  shows  that  the  expressive  power  of 
AVOSW  can  be  reached  only  if  a  path-vector  policy 
system  gives  up  either  transparency  or  some  autonomy. 
However,  both  of  these  may  be  very  important  in  many 
applications.  In  this  section,  we  discuss  an  approach  that 
will  allow  us  to  move  beyond  this  dilemma:  relying  on 
global  assumptions  in  the  network. 

The  expressive  power  of  a  path- vector  policy  system  is 
largely  dictated  by  the  local  constraints  included  in  the 
specification  and  those  enforced  by  the  policy  language. 
We  introduce  the  complementary  notion  of  a  global  con¬ 
straint  as  any  function  K  that  maps  any  (PV,  PL)  in¬ 
stance  I  to  {true,  false}. 

Definition  7.1.  A  globally  constrained  path-vector  pol¬ 
icy  system  is  a  triple  (PV,  PL,  k),  where  K  is  a 
global  constraint  for  (PV,  PL).  I  is  a  legal  instance 
of  (PV,  PL,  k)  if  I  is  an  instance  of  (PV,  PL)  and 
k(7)  =  TRUE. 

Definition  7.2.  Let  M(PV ,  PL,  k)  be  the  set 
{£(5)  |  S  €  S(I)  for  a  legal  (PV ,  PL)  instance  I}. 
Definition  7.3.  Define  the  constraint  K  apo  as 

k  apo(I)  S(I),  £(S)  e  AVOSW. 


We  say  that  the  global  constraint  K  is  robust  for 
(PV ,  PL)  if,  for  every  instance  I.  K (I)  implies  Kapo(I). 

The  following  theorem  implies  that  global  constraints 
are  indeed  an  integral  part  of  path-vector-system  design. 

Theorem  7.4.  Suppose  the  global  constraint  K  is  robust 
for  a  transparent  (PV ,  PL)  allowing  autonomy  of  neigh¬ 
bor  ranking  such  that  Ai(PV sp)  C  fA(PV ,  PL,  k)  (i.e., 
at  least  as  expressive  as  shortest  paths).  Then  K  must  be 
non-trivial. 

Proof.  If  we  are  not  restricted  to  shortest-paths  routing, 
then  autonomy  of  neighbor  ranking  and  transparency  al¬ 
low  us  to  express  BAD  GADGET.  Only  a  non-trivial  global 
constraint  could  prevent  this.  □ 

8  An  Application:  Class-Based 
Path-Vector  Policy  Systems 

The  Hierarchical-BGP  points  in  the  design  space  (HBGP, 
etc.),  motivated  by  [5,  6],  are  examples  of  a  general  class 
of  transparent  systems  where  some  type  of  autonomy  of 
neighbor  ranking  is  relevant:  route  transformations  de¬ 
pend  on  the  partition  of  neighbors  into  classes.  We  will 
refer  to  systems  that  use  a  generalized  version  of  such  a 
policy  language  as  class-based  systems.  Theorem  7.4  tells 
us  that  such  systems  require  a  nontrivial  global  constraint; 
in  this  section  we  sketch  design  guidelines  for  these  sys¬ 
tems. 

8.1  The  Class-Based  Path- Vector  System 

We  fix  a  BGP-like  path-vector  system  that  can  implement 
scoping  and  relative  preference  rules  dictated  by  class  re¬ 
lationships  (such  as  those  in  [5,  6]).  By  scope,  we  mean 
the  conditions  under  which  routes  are  shared  with  neigh¬ 
bors,  and  by  relative  preference,  we  mean  the  difference 
in  rank  assigned  to  routes  learned  from  neighbors  in  dif¬ 
ferent  classes. 

In  our  running-example  system  PV p.bgp,  path  descrip¬ 
tors  r  contain  a  local  preference  attribute  l(r)  that  can 
be  set  to  assign  rank  based  on  the  class  of  the  exporting 
neighbor.  This  attribute  is  not  shared  between  nodes,  intu¬ 
itively  allowing  some  autonomy  and  opaqueness.  Limited 
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scoping  can  be  implemented  by  filtering  routes.  How¬ 
ever,  this  notion  of  scope  is  restrictive,  e.g .,  it  does  not 
allow  easy  flagging  of  a  backup  route,  especially  when 
the  next  hop  might  be  through  a  neighbor  of  an  ordinarily 
preferred  class.  Therefore,  we  extend  the  path  descriptor 
r,  following  [5],  to  include  a  level  attribute  g(r).  This 
attribute  is  nondecreasing  and  shared  and  will  have  prece¬ 
dence  in  ranking;  thus,  it  can  be  used  to  communicate  no¬ 
tions  of  scope  that  override  relative-preference  rules  en¬ 
coded  in  the  local-preference  attribute. 

Remark  8.1.  If  all  nodes  agreed  on  an  encoding  within 
local  preference  for  indicating  backup  routes  or  some 
information  were  shared  between  nodes,  backup-route 
scoping  would  be  possible  in  BGP  (PV ^bgp)  without  ad¬ 
ditional  attributes.  However,  the  additional  attribute  can 
separate  the  awkward  encoding  and  information  sharing 
from  attributes  meant  for  local  use.  The  original  descrip¬ 
tion  of  HBGP+BU  in  [5]  discussed  these  same  issues. 

The  components  of  the  path- vector  system  PV  cb  that 
we  use  for  class-based  applications  are  as  follows. 


TLcb  =  T>cb  x  N  x  N  x  Seq(N) 

Ucb  =  N  x  Z  (lexically  ordered) 
destcb{d,  g,l,  P)  =  d 
LOcb(d,g,l,P)  =  ( g,-l ) 

Ocb(X)  =  (r£  X)  =>  (3d  G  Vcb,  m  G  N 
such  that  r  =  (d,  0,  0,  m)) 
l  £(/)  =  (((d',g',l’,P')  =  f(d,g,l,P)) 

=>  (g<g'  AP  =  P')) 

K'b'(f)  =  m',g',l',P')  =  f(d,g,l,P)) 

=>  (g  <  g'  A  P  =  P')) 

*&(«,«,/,  X)  =  {(d,g,l,P)  G  f(X) 

|  P  is  a  simple  path} 

«,  /,  X)  =  {(d,  g,  0,  uP)  |  (d,  g,  l ,  P)  G  f(X)} 

Note  that  L™b  and  L°bf  guarantee  that  the  level  at¬ 
tribute  is  nondecreasing  and  that  t guarantees  that  lo¬ 
cal  preference  is  not  shared.  When  ranking,  a  smaller 
level  attribute  is  first  preferred,  then  higher  local  pref¬ 
erence.  Also,  note  that  PV  cb  is  transparent:  let 
t(v,  u,  X)  =  {(d  ,g  ,  0,  uP)  |  (d,  g,  l,  P)  G 
X  where  uP  is  a  simple  path}  in  Definition  6.7. 


8.2  Class-Based  Policy  Languages 

The  second  component  of  design  is  a  policy  language  ca¬ 
pable  of  expressing  scope  and  relative-preference  rules  for 
class-based  systems.  We  first  make  formal  the  notion  of 
class  relationships.  Let  C  =  {C±,  62, . . . ,  Cc}  be  a  set  of 
classes.  Every  node  v  G  V  will  have  a  class-assignment 
function  Cv  :  V  — >  C  that  assigns  each  neighbor  of  v  a 
class  in  C.  As  an  example,  consider  node  v  in  Figure  6. 
Here,  a  node  v  with  neighbors  a.  w,  x  has  assigned  classes 
Ck,Ci,  Cj  to  these  neighbors,  respectively. 

cv(w)=q 


Cv(u)=Ck 

/  w 


C’’(*)=  q 


Direction  of  path  descriptor  export 

Figure  6;  Class  assignments  to  neighbors  of  node  v  and 
paths  to  a  destination  node  d. 

Class  assignments  might  require  some  consistency, 
e.g..  that  “customer”  and  “provider”  assignments  occur 
in  consistent  pairs;  such  requirements  in  a  system  are  ex¬ 
pressed  by  the  cross-class  matrix  X  =  {0,  l}cxc-  F°r  any 
pair  of  nodes  u,  v  G  V,  if  Cv(u )  =  Ci.  then  X,:]  =  1  if 
Cu(v )  is  permitted  to  be  Cj ;  otherwise,  X,j  =  0. 

Remark  8.2.  By  defintion,  X  must  be  symmetric. 

Let  (•)  be  the  set  of  order  operators,  e.g.,  =  ,<,<,  etc., 
and  T,  which  means  “any  relationship,”  so  that  Z1TZ2 
is  true  for  any  z\,Zo  in  the  same  ordered  set.  Relative 
preference  between  classes  will  be  described  by  the  pref¬ 
erence  matrix  W  =  (•)cxc  so  that  if  Wl3  =  •,  then 
nodes  should  treat  path  descriptors  rt .  r3  imported  from 
neighbors  in  classes  Ci,Cj,  respectively,  in  a  way  that 
ensures  ujfrf)  •  w(g);  e.g.,  in  Figure  6,  if  Wjj  is  <, 
then  node  v  should  prefer  the  path  P  over  the  path  (). 
The  policy-language  compiler  can  enforce  this  as  a  con¬ 
straint  on  local-preference-attribute  values  set  by  import 
policies. 
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Scope  will  be  described  by  the  level  matrix  M  = 
((•)  U  {1})CXC-  F°r  any  node  v  and  neighbors  w,  u  with 
Cv{w)  =  Ci  and  Cv(u)  =  Ck,  if  =  _L  then  for  any 
path  descriptor  r  imported  from  w,  F  out{v,  it)({r})  must 
equal  0.  This  setting  is  used  to  prevent  the  exchange  of 
routes  between  classes  altogether  (filtering);  e.g.,  in  Fig¬ 
ure  6,  if  Mik  =  _L,  then  v  would  not  export  to  u  any 
routes  it  learned  from  w.  Other  scoping  conditions  can 
be  described  by  allowing  or  enforcing  a  change  in  the 
level  attribute.  One  example  is  backup  routing:  Because 
lower  levels  take  precedence,  a  backup  route  can  be  as¬ 
signed  a  higher  level  value  to  avoid  being  chosen  even  if 
it  passes  through  a  preferred  class.  This  situation  can  be 
sketched  using  our  example  Figure  6:  Formally,  for  any 
node  v  and  two  neighbors  w,u  with  Cv(w)  =  Ci  and 
Cv(u )  =  Cfc,  assume  there  is  a  path  P  from  w  to  some 
destination  d.  Let  rw  be  the  path  descriptor  at  v  for  the 
path  vP,  and  let  ru  be  the  path  descriptor  for  the  path  vP 
exported  to  u,  i.e.,  {ru,}  =  Fout(v,u)({rw}).  The  pol¬ 
icy  compiler  should  enforce  through  constraints  on  level- 
attribute  values  set  in  export  policies  that,  if  •  =  Mu-, 
then  g(rw)  •  g{ru). 

Because  the  level  attribute  has  precedence  in  ranking 
over  the  local-preference  attribute,  the  preference  matrix 
W  only  applies  to  descriptors  of  the  same  level-attribute 
value;  automatically,  lower  level  values  are  preferred  and 
this  allows  descriptors  of  different  levels  to  be  exchanged 
by  neighbors  of  any  class. 


Example  8.3.  For  the  system  HBGP+BU,  let  C  = 
{Ci,  C2,  C3 } ,  where  C\  can  be  interpreted  “customer,” 
C2  as  “peer,”  and  C3  as  “upstream  provider.”  X  should 
enforce  consistent  customer-provider  and  peer-peer  rela¬ 
tionships;  W  should  enforce  that  customer  routes  are  pre¬ 
ferred  over  peer  routes,  and  both  are  preferred  over  up¬ 
stream  routes;  M  should  enforce  that  customer  routes  are 
shared  with  all  neighbors,  and  that  peer  and  upstream 
routes  are  only  shared  with  customers.  In  addition,  M 
should  permit  nodes  to  flag  routes  as  backup  routes  so 
that  they  are  less  preferred  even  if  relative  preference  rules 
would  dictate  otherwise.  The  resulting  matrices  X,  W, 
and  M  are  as  follows. 


X  = 


0  0  1 
0  10 
10  0 
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A  class  description  is  the  quadruple 

CD  =  ( C ,  X,  W,  M). 

CD  contains  all  the  information  necessary  to  generate  a 
policy  language  for  PV  cb  whose  “compiler,”  the  seman¬ 
tic  function  Ad,  can  generate  tuples  (Fm,  Fout ,  F on9) 
from  node  policies  that  (1)  list  class  assignments  {i.e.,  Cv ) 
for  neighbors  and  (2)  give  local  preferences  and  level  set¬ 
tings  for  routes.  The  tuples  will  honor  the  scope  and  rel¬ 
ative  preference  rules  described  by  CD  if  the  compiler 
does  the  following  at  each  node  v  given  its  policy  config¬ 
uration  p  in  PL: 

1 .  For  all  neighbors  u,  let  F  m  ( v ,  u)  set  the  local  prefer¬ 
ence  (and  possibly  level)  attributes  of  imported  path 
descriptors  as  specified  in  the  policy  configuration 
p.  Check  that  for  all  pairs  of  neighbors  a,  w,  if 

Cv{u)  =  Ci,  Cv(w)  =  Cj,  and  •  =  Wij,  then  for 
all  ru  G  F(VjU){ nj)  and  rw  G  F^^Uf),  we  have 
that  u(ru)  •  uj(rw)  if  g(ru)  =  g{rw). 

2.  For  all  neighbors  u,  let  Fout{v,  u)  set  the  level  of 
outgoing  path  descriptors  as  specified  in  the  pol¬ 
icy  configuration  p.  Then  check  that  for  all  pairs 
of  neighbors  u,w,  if  Cv(w)  =  Ci,  Cv(u )  =  Cj, 
and  •  =  Mij,  then  for  all  r  G  F^vw^(JV^), 
g{r)»g{Fout{v,  u){r)),  unless  •  =  _L,  in  which  case 
Fout(v,u)(r)  =  0. 

The  policy  language  can  enforce  the  local  constraints  de¬ 
scribed  by  X,  W,  and  M.  Class  consistency,  along  with 
any  further  conditions  necessary  for  robustness,  must  be 
built  into  the  accompanying  global  constraint. 

Remark  8.4.  Class-based  systems  are  autonomous  with 
respect  to  next-hop  class  if  the  descriptors  have  the  same 
level -attribute  value;  because  a  neighbor  can  be  assigned 
any  class,  as  long  as  the  assignments  are  consistent,  this 
essentially  means  that  class-based  systems  have  a  re¬ 
stricted  form  of  autonomy  of  neighbor  ranking. 
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8.3  Class-Based  Global  Constraints 

Let  the  class-consistency  constraint  C  be  defined  as 

Mu,  v  £  V, 

(Cv(u)  =  Ci)  =>  (Cu(v)  G  {Cj  G  C  |  Xij  =  1}) . 

Let  K cb  =  C  A  J,  where  J  is  some  constraint  such  that  Kc(, 
is  robust  for  P  V  c&  with  respect  to  some  PL  of  the  form 
described  above.  We  now  examine  how  to  suitably  define 
the  robustness  check  J. 

Given  the  results  from  Section  5.2,  we  know  that  a  good 
starting  point  for  guaranteeing  robustness  is  precluding 
dispute  wheels.  Because  of  the  preference  and  scoping 
rules  associated  with  class-based  systems,  we  can  more 
easily  find  potential  dispute  wheels  given  the  class  assign¬ 
ments  made  by  nodes.  We  first  introduce  the  following 
helpful  result. 

Lemma  8.5.  The  path  descriptors  corresponding  to  all 
paths  RtQi+i  and  Qi  on  a  dispute-wheel  rim  in  an  SPP 
mapped  from  a  class-based  instance  have  equal  level- 
attribute  values. 

Proof.  In  this  proof,  SPPs  are  those  mapped  from  in¬ 
stances  of  a  path- vector  system;  so,  if  P  G  Vv  in  the 
SPP  S  G  S(I),  define  d(P)  G  1Zcb  as  the  realizable  path 
descriptor  for  path  P  at  node  v  in  the  path-vector  instance 
I.  Recall  that  g(r)  is  the  level  attribute  of  r. 

Assume  we  have  a  dispute  wheel  in  some  SPP 
S  G  S(iy,  then  for  all  i,  XVi  (RiQi+1)  <  A Vi(Qf), 
so  u>(d(RiQi+ 1))  <  u)(d(Qi));  this  means  that 

g(d(RiQi+ 1))  <  g(d(Qi)).  Level  is  nondecreasing,  so 
g(d(Qi+ 1))  <  g(d(RiQ  j+i)).  These  two  inequalities 
imply  that  g(d(Qi+ 1))  <  g(d(Qi))  for  all  i\  iterating 
around  the  wheel  yields  g(d(Qij)  <  g(d(Qi+ 1)),  thus 
g(d(Qi))  =  9{d{Qi+ 1))  =  g(d(RiQi+i)).  □ 

Let  e  =  {v,  u}  G  E  and  let  Cv{u)  =  Ci.  If  e  is  on 
a  dispute  wheel  rim,  then  by  Lemma  8.5,  there  must  be  a 
class  assignment  of  another  node  w  by  v  such  that  v  can 
export  to  u  a  path  descriptor  from  w  without  increasing 
the  level  attribute.  But  when  an  edge  lies  on  a  dispute 
wheel  rim,  it  imports  a  descriptor  from  two  nodes,  one 
along  a  spoke  edge  and  one  also  on  the  rim;  so,  this  con¬ 
dition  is  true  for  both  the  node  adjacent  to  the  spoke  edge 
leading  to  v  and  for  the  node  adjacent  to  the  rim  edge 


leading  to  v.  This  condition,  in  turn,  applies  to  the  rim 
edge  {iu,  u}  as  well  (a  dispute  wheel  must  contain  at  least 
two  distinct  directed  edges),  but  we  cannot  iterate  further 
around  the  wheel  because  w  could  import  from  rim  edge 
e.  However,  we  have  just  proved  that  the  following  state¬ 
ment  must  hold  for  any  rim  edge  e: 

Lemma  8.6.  If  e  =  {v,  u}  G  E  with  Cv{u)  =  Ci  is  on 
a  dispute-wheel  rim,  then  there  exists  some 

Cj  G  {Cx  |  Xjx  =  1  and  Mxi  permits  equality} 
such  that 

3k  :  Mkj  =  1. 

We  can  then  use  Lemma  8.6  to  form  a  constraint  that 
prevents  dispute  wheels  just  based  on  class  assignments: 

Theorem  8.7.  Given  an  instance  signaling  graph  G  and 
class  assignments,  consider  the  subgraph  H  containing 
only  edges  {u,  u},  Cv(u)  =  Ci,  with  Ci  satisfying  the 
condition  in  Lemma  8.6.  If  H  is  acyclic  then  there  is  no 
dispute  wheel. 

Proof.  Dispute  wheen  rims  must  contain  edges  satisfying 
the  condition  in  Lemma  8.6.  Thus  if  the  signaling  sub¬ 
graph  containing  only  these  edges  is  acyclic,  no  cycle  of 
these  edges,  including  a  dispute  wheel  in  the  general  sig¬ 
naling  graph,  is  possible.  □ 

Remark  8.8.  The  sufficient  condition  in  Theorem  8.7  is 
unnecessarily  strong  in  most  cases.  However,  if  W  = 
Tcxc  then  this  is  the  only  global  constraint  we  know  of 
that  can  guarantee  no  dispute  wheel.  Furthermore,  M  of¬ 
ten  permits  the  construction  of  a  “homogeneous  dispute 
wheel,”  one  where  all  class  assignments  in  the  direction 
of  export  are  the  same  around  the  rim.  The  constraint  in 
Theorem  8.7  can  be  weakened  to  allow  such  cycles  in  the 
testing  subgraph  and  these  cycles  can  then  be  checked  for 
separately.  This  observation  is  especially  important  for 
HBGP+BU,  where  the  only  potential  dispute  wheels  are 
homogeneous,  and  these  cycles  are  prevented  by  standard 
Internet  economics  (see  the  following  example). 

Example  8.9.  For  the  system  HBGP+BU,  J  need  only 
check  that  no  customer-provider  cycles  exist:  A  sim¬ 
ple  case-by-case  analysis  of  possible  class  assignments, 
given  the  constraints  in  matrices  C  and  M,  shows  that  the 
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only  dispute  wheels  possible  are  cycles  in  the  customer- 
provider  relationship  graph.  This  follows  directly  from 
Lemma  8.5.  Consider  the  other  possibilities  of  edges  on 
the  dispute  wheel: 

1.  Suppose  we  have  a  rim  edge  e  =  {i>,  u}  where 
Cv(u )  =  C3.  Then  node  v  must  import  from  a 
node  w  without  increasing  the  level  attribute;  how¬ 
ever,  only  M31  permits  equality  so  Cv(w)  =  C\. 
Because  only  X13  —  1,  we  have  that  Cw(v )  =  3.  If 
w  is  on  a  spoke,  then  because  W  prefers  routes  from 
C\  neighbors  such  as  w,  the  adjacent  rim  node  must 
also  be  of  class  C 1.  Thus  the  only  situation  is  one 
where  the  adjacent  rim  edge  to  v  must  have  the  same 
assignment  as  this  one;  this  gives  the  homogeneous 
customer-provider  cycle. 

2.  Suppose  we  have  a  rim  edge  e  =  {i>,  u}  where 
Cv(u )  =  Cn-  Just  as  with  the  case  above,  only 
M21  permits  equality,  and  by  a  similar  argument,  the 
adjacent  rim  edge  to  v  must  be  a  customer-provider 
edge.  But  this  results  in  case  (1)  above  where  the 
dispute  wheel  must  have  these  edges  all  the  way 
around  the  rim,  which  contradicts  the  assumption 
that  Cv(u)  =  C2.  Thus  this  edge  e  cannot  be  on 
a  dispute  wheel. 

3.  Suppose  we  have  a  rim  edge  e  =  {v,  u}  where 
Cv(u )  =  Ci.  All  values  Mu  permit  equality,  so  v 
can  import  the  dispute  path  descriptors  from  neigh¬ 
bors  of  any  class.  Consider  the  assigment  along  the 
rim  edge  e'  =  {w,  v}  adjacent  to  v.  By  case  (2) 
above,  Cw(v)  ^  C2-  If  Cw(v)  =  C3  then  all  dis¬ 
pute  wheel  edges  must  have  this  directed  assignment, 
as  in  case  (1)  above,  so  this  contradicts  the  assumed 
class  assignment  along  edge  e.  The  only  other  pos¬ 
sibility  is  that  Cw( v)  =  Ci,  which  would  give  a 
customer-provider  cycle. 

Checking  for  these  customer-provider  cycles  is  tractable; 
even  without  an  explicit  check,  the  basic  economics  of  the 
current  commercial  Internet  naturally  prevent  nodes  from 
being  customers  or  providers  of  themselves. 


9  Open  Problems 

We  have  defined  the  Path- Vector  Policy  System  frame¬ 
work:  we  identified  and  formalized  dimensions  of  the  pro¬ 
tocol  design  space  in  a  way  that  highlights  the  role  of  pol¬ 
icy  languages. 

Several  issues  that  we  discussed  require  additional 
work.  First,  either  Conjecture  5.3  must  be  proven  or 
a  broader  sufficient  condition  for  robustness  should  be 
found.  Second,  the  power  of  class-based  systems  must 
be  investigated  further;  in  particular,  the  robustness  check 
presented  in  Theorem  8.7  is  too  strong.  It  is  likely  that 
a  closer  examination  of  the  preference  and  scoping  rules 
will  give  a  more  reasonable  set  of  constraints  that  do  not 
“over-protect”  against  dispute  wheels  and  do  not  preclude 
too  many  robust  instances.  Third,  while  we  justify  the  in¬ 
clusion  of  global  constraints  in  protocol  design,  we  do  not 
discuss  how  they  are  enforced.  Distributed  algorithms, 
supplementary  protocols,  or  economic  incentives  could 
check  global  consistency.  We  can  also  ask  what  level  of 
expressiveness  can  be  achieved  by  an  autonomous,  trans¬ 
parent,  and  robust  system  with  an  imposed  global  con¬ 
straint  that  can  be  checked  by  one  of  the  above  methods 
in  polynomial  time.  Finally,  additional  useful  degrees  of 
autonomy  should  be  identified  and  analyzed  (perhaps  in 
the  context  of  specific  routing  applications). 

We  have  focused  on  the  static  semantics  of  path-vector 
systems  rather  than  their  dynamic  behavior.  However,  in 
non-deterministic  systems,  the  static  and  dynamic  seman¬ 
tics  may  become  intertwined,  e.g.,  a  node  might  use  some 
temporal  condition  to  break  ties  between  equally  ranked 
routes  from  different  neighbors  in  a  BGP-like  system — a 
system  that  prefers  more  recent  routes  will  have  very  dif¬ 
ferent  semantics  than  one  that  prefers  older  routes.  Both 
non-deterministic  systems  and  their  dynamic  semantics 
should  be  investigated.  Furthermore,  the  static  semantics 
of  a  path-vector  system  are  independent  of  the  algorithm 
used  to  find  solutions;  we  are  particularly  interested  in 
distributed  approaches  to  this  problem. 

We  have  focused  on  the  signaling  of  routes  without 
discussion  of  how  this  corresponds  to  forwarding  in  the 
data  plane.  For  example,  in  BGP,  the  signaling  graph  of 
Internal  BGP  (IBGP)  need  not  have  any  relationship  to 
the  forwarding  graph  (IGP  forwarding).  Several  routing 
anomalies  that  are  related  to  this  independence  in  BGP 
have  been  described  elsewhere  in  [11],  In  general,  there 
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will  be  some  interaction  between  the  signaling  graph,  the 
physical  network  supporting  this  signaling,  and  the  paths 
in  the  data  plane  which  are  controlled  by  the  paths  in  the 
signaling  plane.  We  need  a  general  theory  that  describes 
this  interaction  for  path- vector  protocols. 
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A  Proofs  of  SPP  and  Path-Vector 
Solution  Equivalence 

Theorem  A.l  (4.5).  If  it  is  a  solution  for  S^j,Wtrwy  then 
Pn(v)  =  [J  r(P,  rw) 

P(z7r(v) 

is  a  solution  for  /(to,  rw). 

Proof  It  is  clear  that  for  each  v,  all  path  descriptors  in 
pn(v)  are  realizable.  We  must  show  that  for  each  v, 
P-kW)  =  min(C'(p7r,  o)).  If  o  =  to,  then  pn(w)  = 
{(to)}  =  min (C(pn,  to))  by  definition.  Suppose  that 
v  to.  We  first  note  that  for  any  Y  C  Vv , 

A  =  (J  r(P,  rw) 

P Gmin(A”,  Y) 


=  B, 

because 

r  G  A 

iff  {r}  =  r(P,  rw)  for  some  P  G  min(A'u,  Y) 
iff  {r}  =  r(P,  rw )  for  some  P  GY  such  that  for 
every  P'  G  Y,  A)’,,  rJP)  <  A^  B,  rw){P') 
iff  for  some  P  GY  such  that  for  every  P'  GY, 

M  =  r(P,  rw),  {?■'}  =  r(P,  rw), 
and  co(r)  <  oo(r') 

iff  for  all  r'  G  (Upey  r(p ’>  rw)),  w(r)  <  w(r') 
iff  r  G  B. 


Let  Y  =  {( vQ  G  Vv  |  {o,  u}  G  E  and  Q  =  7r(tt)}. 
Because  7r  is  a  solution  we  have  tt(v)  =  min(A11,  Y)  and 
we  have 

Pn(v) 

—  U P£tz(v)  r(P’  Vw) 

=  Upemin(At’,  Y)  r(Pi  r™) 

=  min([JP6F  r(P,  rw)) 

=  min({r  G  TZ  \  r  G  r(P,  rw)  for  some  P  GY}) 

=  min({r  G  TZ  \  r  G  r(P,  rw)  for  some 

P  G  {(vQ  G  Pv  |  {o,  u}  G  E  and  Q  =  7r(u)}}) 

=  min({r  G  TZ  |  {o,  u}  G  E  and 

r  e  Uqs^u)  r(vQ,  rw)}) 

=  min({r  G  TZ  |  {o,  u}  G  E  and 

r  ^  U<5g7t(m)  P(v,  u)(r(Q,  fu,))}) 

=  min({r  G  TZ  |  {o,  u}  G  E  and 

r  e  F(V,  «)(UQgw(M)  r(Q,  Go))}) 

=  min({r  G  TZ  |  {o,  u}  G  E  and 
r  G  P(„,  «)(pff(ti))}) 

=  min (C(pn,  o)), 

which  completes  the  proof.  □ 


Theorem  A.2  (4.6).  If  p  is  a  solution  for  /(to,  rw),  then 
nP(v)  =  {P  GPV  |  r(P,  rw)  C  p(v)} 
is  a  solution  for  S(i  w>rwy 

Proof  We  need  to  show  that  for  each  v  we  have  7r p(v)  = 
min( A’',  candidates(t),  7Tp)).  Because  p  is  a  solution 
for  /(to,  rw),  we  know  that  p( v)  =  C(p,  v )  = 

min (Fori9(v)  U  Y),  where 

Y  =  {r  G  TZ  \  {v,  u}  G  E  and  r  G  P(„,  u)(p(u))}. 

It  is  easy  to  show  that  for  any  X  we  have 

{P  G  Vv  |  r(P,  rw)  C  min(X)}  = 

min(A \{PGVV  |  r(P,  rw)GX}). 
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When  v  ^  w,  then 


=  {PeVv  |  r(P,  rw)  C  p(r;)} 

=  {P  G  Vv  |  r(P,  rw)  C  min(F)} 

=  mm(Xv,{PeVv  \r(P,  rw)C 

{r  £  11  |  {v,  u}  G  P  and  r  G  P(„_  „)(p(u))}}) 

=  min(At',  {(vQ  G  Vv  \  {v,  u}  £  E  and 
Q  =  {P'  g  Vv  |  r(P',  rw)  C  p(u)}}) 

=  min(At',  {(wQ  €  Pu  |  {u,  w}  G  E  and 

Q  =  TtpO)}) 

=  min(At',  candidates(y, 7TP)) 

When  v  =  w,  note  that  p(y)  =  {rw},  so  we  have 
np(v)  =  {P  £  Vv  |  r(P,  rw)  C  {r™}}  =  {(to)}  = 
min  (A",  candidates^,  np)).  □ 

Theorem  A.3  (4.7).  7r Pw  =  7r  and  p7rp  =  p. 

Proof. 

7r(v) 

=  {P£PV  |  0  ^  r(P,  rv,)  C  UQ&r(„)  r(Q,  r„,)} 

=  {P  G  P" | 0  ^  r(P,  rw)  C  p»} 

=  TTp,  (u) 

p(v) 

=  UpG({PGP”|0#r(P,  r„)Cp(»)})  r(^  r«>) 

=  Upg^G)  r(P,  rw) 

=  PTTp(tt). 

□ 


B  Topologically  Sorting  SPPs 

Theorem  B.l.  If  S  £  AVOSVV  then  there  exists  an 
instance  S'  £  TSW  such  that  S'  £  £(S). 

Proof  We  give  an  iterative  process  converging  to  a  path¬ 
ranking  function  A  that  is  increasing. 

Define  the  path-rank  function  for  node  v  at  step  k  to  be 
Xvk.  For  all  v  £  V  and  P  £  Vv ,  let  A %(P)  =  oo  for  all 
k  <  0.  For  k  >  0,  define  Aj’  as  follows:  At  every  node 
v  ^  Vo,  consider  exactly  the  paths  permitted  at  v,  Vv, 
which  have  the  form  vuP' ,  where  either  u  =  v o  and  P'  = 
eorii^  vo  and  uP'  £  V1 .  List  these  in  decreasing  order 
of  preference  as  Pi  =  vu\P[ ,  P2  =  VU2P2 ,  •  •  • ,  Pi  = 


vuiP-.  (Ties  can  be  broken  arbitrarily.)  If  u  1  =  vq,  then 
let 

A£+i(Pi)  =  1, 

and  if  U\  vo  let 

Afc+i(Pi)  =  A“1(P1,)  +  l- 

For  the  less  preferred  paths  P3,  2  <  j  <  i,  if  Uj  =  Vq,  let 

Afc+i  (Pj )  =  K(Pj-i)  +  1, 

and  for  Uj  ^  Vq  let 

Afc+i(Pj)  =  max {A^ (Pj),  A^P^)}  +  1. 

Assume  that  all  undefined  values  of  A  are  00  in  the  above. 

Assuming  that  the  set  of  permitted  paths  is  closed  un¬ 
der  the  taking  of  subpaths,  if  the  longest  permitted  path 
in  the  SPP  has  k  edges,  then  for  all  v  G  V  and  for  all 
P  G  Vv ,  Xuk,  (P)  00  for  every  k'  >  k.  The  path- 

rank  functions  will  stabilize  over  iterations  if  the  SPP  S  is 
almost-partially  ordered,  so  in  S',  let 

AO)  =  lim  A %. 

«— XX) 

Note  that  in  using  the  above  iterative  process,  ranks 
are  always  set  higher  than  neighboring  ranks  because  of 
the  increment  used  in  defining  A):.  Indeed,  A v(vuP)  > 
Xu(uP)  after  convergence,  thus  A  and  S'  are  increasing. 

Finally,  it  is  clear  that  S'  £  £(S),  because  the  rank¬ 
ing  given  by  the  converging  import  functions  is  consistent 
with  the  SPP  preference  list  at  every  node.  □ 

Remark  B.2.  Any  almost-partially  ordered  SPP  can  be 
convered  to  an  increasing  SPP  using  the  method  described 
above.  It  can  also  be  shown  that  an  SPP  which  cannot 
converge  with  respect  to  the  above  process  (i.e.,  for  some 
P  G  Vv,  there  does  not  exist  any  integer  k'  such  that 
Al-  (P)  7^  00  for  k  >  k ')  must  have  a  dispute  wheel  and 
thus  is  not  almost-partially  ordered. 
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